Fork us on GitHub Follow us on Facebook Follow us on Twitter

Opened 11 years ago

Closed 11 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)

ticket273.patch (22.0 KB) - added by Petr Koupy 11 years ago.

Download all attachments as: .zip

Change History (6)

comment:1 Changed 11 years ago by Jakub Jermář

Milestone: 0.4.30.5.0

comment:2 Changed 11 years ago by Jakub Jermář

Type: defectenhancement

comment:3 Changed 11 years ago by Petr Koupy

Owner: set to Petr Koupy
Status: newassigned

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.

Last edited 11 years ago by Petr Koupy (previous) (diff)

Changed 11 years ago by Petr Koupy

Attachment: ticket273.patch added

comment:4 Changed 11 years ago by Petr Koupy

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 Changed 11 years ago by Jakub Jermář

Resolution: fixed
Status: assignedclosed

Fix merged in changeset:mainline,902.

Note: See TracTickets for help on using tickets.