GNU Astronomy Utilities - Bugs: bug #51603, Lost memory when re-writing option...
You are not allowed to post comments on this tracker with your current authentication level.
bug #51603: Lost memory when re-writing option value
Submitter: | Mohammad Akhlaghi <makhlaghi> | ||
Submitted: | Fri 28 Jul 2017 11:35:58 AM UTC | ||
Category: | All Gnuastro | Severity: | 2 - Minor |
Item Group: | Addition(s) | Status: | Postponed |
Privacy: | Public | Assigned to: | None |
Open/Closed: | Open |
No files currently attached
Depends on the following items: None found
Items that depend on this one: None found
Carbon-Copy List
There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.
No changes have been made to this item
Powered by Savane 3.13-f8d8.
Corresponding source code
On the command-line, the last invocation of a single-valued option is used as its final value.
This is implemented in `gal_options_set_from_key' (of lib/options.c) by simply giving the `set' element the value of `GAL_OPTIONS_NOT_SET'.
This is fine when the memory for the option value is static. But when it is allocated, it will result in the loss of the allocated piece of memory (the pointer will be changed and we loose the address of the allocated memory).
By definition, such allocated pieces of memory aren't usually larger than a few bytes and this bug thus won't cause any problem for the user. But it would be good if we could solve it for things to be clean as possible.
One solution that comes to my mind now is to set another flag in `struct argp_option' (of `bootstrapped/lib/argp.h' which is modified during bootstrapping in bootstrap.conf). This flag can say that memory for this option value is allocated or static. Using this flag, we can then free the space if necessary before setting the `set' flag to `GAL_OPTIONS_NOT_SET'.
But I don't have time to implement this right now and it isn't a major issue. So if you are interested, your help would be very welcome.