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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
