Skip to content

Commit

Permalink
ta: destroy/free children in reverse order
Browse files Browse the repository at this point in the history
This matters when talloc allocations set destructors. Before this
commit, destructors were called in the same order as they were added to
the parent allocations. Now it happens in reverse order.

I think this makes more sense. It's reasonable to assume that an
allocation that was added later may depend on any of the previous
allocations, so later additions should be destroyed first. (Of course
other orders are entirely possible too.)

Hopefully this doesn't fix or break anything, but I can't be sure (about
either of those). It's risky. (Then why do it?)

The destructor of a parent allocation is called before its children. It
makes sense and must stay this way, because in most cases, the
destructor wants to access the children.

This is a reason why I don't really like talloc (it wasn't my idea to
use talloc, is my excuse). Quite possible that destructors should be
removed from talloc entirely. Actually, this project should probably be
rewritten in Rust (or a better language), but that would be even more of
a pain; also, I think this is just the right level of suffering and
punishment.
  • Loading branch information
wm4 committed Sep 19, 2019
1 parent 0edccfd commit 36dd234
Showing 1 changed file with 2 additions and 2 deletions.
4 changes: 2 additions & 2 deletions ta/ta.c
Original file line number Diff line number Diff line change
Expand Up @@ -246,8 +246,8 @@ void ta_free_children(void *ptr)
struct ta_ext_header *eh = h ? h->ext : NULL;
if (!eh)
return;
while (eh->children.next != &eh->children)
ta_free(PTR_FROM_HEADER(eh->children.next));
while (eh->children.prev != &eh->children)
ta_free(PTR_FROM_HEADER(eh->children.prev));
}

/* Free the given allocation, and all of its direct and indirect children.
Expand Down

0 comments on commit 36dd234

Please sign in to comment.