Closed Phelimb closed 9 years ago
This is the whole issue of having a clear policy of ownership. It is indeed confusing and a source of bugs to free and malloc in different files. If we were writing in C++, you'd have an object which contained a constructor for malloc and a destructor for free, but you would still have the issue of knowing whose job it is to destroy an object. In our case the system is very simple - we don't have complex objects being created all over the place at runtime and being passed back and forth. Hold on - I'll take a look at your proposed change
This looks fine.
boolean non_aureus_panels_are_present(SpeciesInfo* species_info){ boolean* mask = create_non_aureus_mask(); boolean non_aureus_species_panels_are_present = panels_are_present(species_info->species_covg_info,mask);
One simple and effective thing we could do is have functions which alloc and return an object, ownership of which is transferred to the caller, have a certain word in the function-name. eg create, in fact! Anyway - this chunk, where you alloc, use, and free, seems fine. One sec, going back to code.
I think this looks fine.
"Is the alternative is to alloc the masks within the correct scope and then use void functions to update them? Is this the recommended method do you know?"
the alternatives are
I think your solution is fine. Have you checked it with valgrind?
Happy to merge this once valgrind checked
Spoke to Phelim - he has checked with valgrind. Fixes the leaks it is intended to fix. Still more to do.
@iqbal-lab this is just the first of these memory leaks but just wanted to get your opinion on this solution. Is this what you would have suggested doing? Simply freeing mask when finished. It seems a little confusing to me when the free isn't even in the same file as the malloc.
Is the alternative is to alloc the masks within the correct scope and then use void functions to update them? Is this the recommended method do you know?