Memory issues with igh projection

[gmunro]

I received a few valgrind complaints when testing the new igh projection:

==6760== 240 bytes in 6 blocks are definitely lost in loss record 49 of 53
==6760==    at 0x4004A41: malloc (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
==6760==    by 0x44DF05C: pj_malloc (pj_malloc.c:19)
==6760==    by 0x44DF0B7: pj_enfn (pj_mlfn.c:26)
==6760==    by 0x44D53BD: pj_sinu (PJ_gn_sinu.c:70)
==6760==    by 0x44D6119: pj_igh (PJ_igh.c:155)
==6760==    by 0x44DE9E9: pj_init_ctx (pj_init.c:426)
==6760==    by 0x44DEDE8: pj_init_plus_ctx (pj_init.c:210)

The freeup method should be calling the projection's free method rather than the system's free.

==1539== Conditional jump or move depends on uninitialised value(s)
==1539==    at 0x44D53F0: pj_sinu (PJ_gn_sinu.c:72)
==1539==    by 0x44D6308: pj_igh (PJ_igh.c:163)
==1539==    by 0x44DEAFC: pj_init_ctx (pj_init.c:443)
==1539==    by 0x44DEF68: pj_init_plus_ctx (pj_init.c:210)

pj_sinu can potentially read the 'es' value without it being initialized. It isn't good to assume it will be initialized to null. You can probably modify the put in and ENTRYA/ENTRYX solution here. But I wonder if it would be better to use calloc or a memset in pj_malloc to avoid other similar issues?

[warmerdam]

I chose to do the memset a bit more narrowly - just in the ENTRY macro (r2045).

I hand applied your PJ_igh patch in trunk (r2046, r2047).

Thanks!