On Fri, Feb 25, 2022 at 10:24:14AM -0800, Junio C Hamano wrote: > > Not so fast. I still do not see a strong reason to support > xdl_malloc() and other wrappers. git has an `xmalloc` but no matching `xfree`. libgit2 does not necessarily use the system allocator (and on Windows, you run into the question of _which_ system allocator you're using) and therefore has its own allocation _and_ deallocation functions. When libgit2 includes xdiff, I don't want to monkey around and try to redefine `free` to our deallocator. There are several options that could suffice for this. A different tactic is to have xdiff call `xfree` which is just defined as `free` in git. This would feel non-obvious to me as a git developer that in this one part of the project, I need to use `xfree` instead of `free` on memory that I have `xmalloc`ed. Using a net new name for allocation functions may help serve as a reminder that it is a different API. > Is the expectation for other projects when using the unified code, > they do not use xdiff/git-xdiff.h and instead add > xdiff/frotz-xdiff.h that defines xdl_malloc() and friends with the > infrastructure they provide as part of the Frotz project (and the > Xyzzy project would do the same with xdiff/xyzzy-xdiff.h header for > them), making "git" the first among equal other consumers? No, the thinking is that they would provide their own `git-xdiff.h` that defines the mappings to their project-specific APIs. Cheers- -ed
