Hi Jelmer, > It would be nice to standardize on one or the other though rather than > using a strange mix of both. Should we encourage the use of > TALLOC_FREE() over talloc_free() ?
They are different calls. We certainly should not deprecate the use of talloc_free(). A TALLOC_FREE() only makes sense at all when the variable you are freeing is long term. If it's a stack variable then it usually makes no sense. It also loses information. As someone already pointed out, we get a nice talloc double free report when you re-use a free ptr. That report includes the location of the first free, which is encoded in the memory block. If you use TALLOC_FREE() then the 2nd free becomes allowed (as talloc_free(NULL) does not abort). You may well end up with a segfault, which is also useful, but the backtrace from the segfault gives you no idea where the first free was, as you've wiped that information with TALLOC_FREE(). I've used that "double free error - first free may be at xxx.c:yyy" report to find many subtle bugs. I know some people are committed to TALLOC_FREE(), and that's fine, but let's please not go so far as to deprecate the function that gives us better debugging ability. Cheers, Tridge
