Re: [PATCH 1/2] Introduce leaky().

[Junio C Hamano <gitster@pobox.com>]

I looked at the patch (and your updated parseopt series that depends on
this that is queued at madism.org) again, but I have to say I do not like
it, not because I do not want leaks, nor because I do not want explicit
markings.  The issue of helping valgrind sessions is worth addressing.

However.

First of all, it is unclear what the semantics of leaky() is.  Do you want
to mark all things that will be unreacheable from anywhere in the program
at the end, or do you want to mark all things that we have obtained from
malloc(3) and friends but have not free(3)ed?  Without a clear semantics
to use as the guiding principle, it would be hard for people to use this
macro properly to help debugging leaks.

Specifically, how would you envision to handle allocations of objects that
will be reachable from object.c::obj_hash at the program end?  We do not
have to (and we should not) mark them using the former semantics, but we
should with the latter semantics.

The user would also need to worry about not freeing the original
allocation pointer when something is realloc(3)ed, which means either
finding the last realloc(3) of the object (that is logically the same, but
just being extended) and mark the pointer as leaky() after that realloc,
or unregister the original pointer from leaks before calling realloc and
register what comes back.  It will easily get messy.

By the way, the series queued in your repository still has "s/pring/print/"
typo in 4/7 and "argv not NULL terminated" comment in 6/7.