Fix pc_patch_compress leak

[achidlow]

This fixes a memory leak in pc_patch_compress. See issue #111.

[mbredif]

I came across this issue as well :

• pc_patch_dimensional_free(pcdu); is not equivalent (as one could expect) with pc_patch_free((PCPATCH*)pcdu); because it does not free the stats (https://github.com/pgpointcloud/pointcloud/blob/master/lib/pc_patch.c#L85-L89).

They could be made equivalent, saving a upcast-switch-downcast round-trip by putting the stats-freeing code (possibly wrapped in a function such as pc_patch_common_free(PCPATCH*) ) in all the pc_patch_*_free specialized functions.

[achidlow]

@mbredif that sounds like a better idea, that would fix any other similar leaks in one go. I'll get on it.

[achidlow]

Okay I've made the change @mbredif suggested and made a separate pc_patch_common_free function. This actually revealed an error in pc_patch_dimensional_compress where the stats member was set by memcpy from another PCPATCH_DIMENSIONAL resulting in a double-free. So I went through every case of pcalloc(sizeof(PCPATCH* to make sure the stats member was being set correctly, either to NULL or through pc_stats_clone

[strk]

Is there an existing test in the testsuite that would make the leak evident (and confirm the fix) ?

[mbredif]

I have just stumbled yet again on this issue while addressing #135 in mbredif/pointcloud/pointlist_data.

The non-equivalence of pc_patch_*_free(pa) with pc_patch_free((PCPATCH*)pa); is so easy oversee...

I included a quick fix but this PR would be more relevant.

[elemoine]

The non-equivalence of pc_patch__free(pa) with pc_patch_free((PCPATCH)pa); is so easy oversee...

That's right, but couldn't the rule be "never call pc_patch_[something]_free, and always call pc_patch_free"?

[elemoine]

Replaced by #206.