Opened 14 years ago
Closed 14 years ago
#273 closed enhancement (fixed)
The map ADT should not free the object if its addition to the map failed
Reported by: | Jakub Jermář | Owned by: | Petr Koupy |
---|---|---|---|
Priority: | major | Milestone: | 0.5.0 |
Component: | helenos/lib/c | Version: | |
Keywords: | Cc: | ||
Blocker for: | Depends on: | ||
See also: |
Description
The map ADTs (e.g. the generic char map) will free up the memory for an object which it failed to insert (e.g. it was already there or it ran out of memory during the add operation).
In fact, the map ADTs should never free the memory occupied by the mapped object. The current networking code may rely on this behavior, but this should rather be changed.
Attachments (1)
Change History (6)
comment:1 by , 14 years ago
Milestone: | 0.4.3 → 0.5.0 |
---|
comment:2 by , 14 years ago
Type: | defect → enhancement |
---|
comment:3 by , 14 years ago
Owner: | set to |
---|---|
Status: | new → assigned |
by , 14 years ago
Attachment: | ticket273.patch added |
---|
comment:4 by , 14 years ago
Operation for adding items into generic_char_map no longer deallocates given
object (i.e. behaves the same way as int_map and generic_field, leaving the
deallocation to the user).
Operations for exclusion and destruction of items in generic_char_map, int_map
and generic_field accept new argument - function pointer to the user-defined
destructor of the mapped objects. NULL pointer might be passed to allow fully
manual deallocation in the user code. Pointer to generic free() might be
passed as well.
Minor modifications have been made to the dependent networking code to work
with the new interface.
comment:5 by , 14 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
Fix merged in changeset:mainline,902.
I understand the issue and have located all the dependencies. Before incorporating the fix, I request the author of the ticket to further specify the expected behaviour - mainly to clarify the sentence "map ADTs should never free the memory occupied by the mapped object". I recognize two possibilities:
1) All operations of map ADTs shall be strictly shallow, leaving the deallocation of contained objects to the user. As an example, user would be obliged to free all mapped objects before calling destroy operation on map ADT. Such solution would however require the user to actually remember the keys. This would ultimately result in a major surgery to some networking files and seems rather impractical.
2) The goal of the ticket would be redefined to the removal of inconsistency between add and remove operation (i.e. add would never cause internal deallocation). Remove and destroy operations would be provided in two versions - shallow and deep. Of course, the deep version would guarantee just a single level deallocation due to the absence of destructors. Dependent networking code would be then checked for the correct usage and possible memory leaks.