On Fri, 9 Aug 2013 16:10:39 +0200, David Sterba wrote: > On Wed, Aug 07, 2013 at 10:17:57AM -0500, Eric Sandeen wrote: >> And isn't it still a mistake? I think it used to be that >> subvol_uuid_search_init() >> would allocate the memory which must be freed, but that's no longer the case, >> right? So under what circumstances is it correct to call >> subvol_uuid_search_add() which frees those pointers? > > Looks like the memory management is internal to the subvol_uuid* > functions, now _init does not allocate and I don't see why _add should > call free. All users of subvol_uuid_search() free the memory themselves > (in current code). > > Seems that subvol_uuid_search_add was exported without any concern that > it could be part of the library interface. > > We don't have library ABI versioning in place, so I suggest to keep the > function there for compatibility with current code (though I'm not aware > of any external users of the _add function), but drop th free() calls > and put a "don't use" comment. >
Callers of the subvol_uuid interface (like Btrfs receive) allocate the memory for newly created items (this is the case after receiving a subvolume) and add them to the database with the _add function. _add() stores the pointer and the caller mustn't free() the item. This was/is the interface. We don't have this database anymore, we don't keep the items that are added. Since it was not allowed to call free() for items that have been added, _add() must call free() now. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
