On Mon, Aug 04, 2025 at 12:14:22PM -0700, Junio C Hamano wrote:
> Patrick Steinhardt <ps@xxxxxx> writes:
>
> > Yeah, in general I'm also of the opinion that we shouldn't bother. But
> > in libgit2 we have pipelines that use such older compilers, and we don't
> > want to drop those for now. So I think we should treat the reftable
> > library specially, doubly so as this is the only instance that causes
> > problems.
>
> Hmph. Shouldn't there be some kind of "shim" layer where these
> things are defined per project convention and/or toolchain being
> used? So when building for git proper, you'd use {0} just as
> everybody else do, but for others your include file supplied by that
> project would use something else (like {{0}} in this case)? That
> kind of approach would be a better solution than open coding QSORT()
> in the longer term, for example.
We do have a shim layer, but I don't think it makes sense to use it for
every small piece. The intent of that layer is to paper over platform
differences that we cannot easily hide away in a generic fashion. So
things like mmap, random numbers, handling includes or registering
lockfiles via atexit(3p).
But I don't think it makes sense to use the shim layer for things like
`{0}` vs `{{0}}` or `QSORT()`. It doesn't really have any downside to
change to `{{0}}`, and the one invocation of `QSORT()` is trivial to
convert to qsort(3p) and unlikely to cause any more maintenance in the
long run than the invocation of `QSORT()` would.
On the other hand, it does have a downside if we moved all of this into
the shim layer, because now every user of the reftable library will have
to reinvent the wheel. The other downside is that the more we move into
the shim layer, the more the different implementations of the reftable
backend may diverge in behaviour. Reversely, the more code is the exact
same across implementations the more we can benefit from the tests that
those other implementations use and the more solid the reftable library
becomes.
Patrick
