git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Patrick Steinhardt <ps@pks.im>
To: Junio C Hamano <gitster@pobox.com>
Cc: Eric Sunshine <sunshine@sunshineco.com>, git@vger.kernel.org
Subject: Re: [PATCH 3/5] reftable/stack: fix compiler warning due to missing braces
Date: Tue, 5 Aug 2025 06:49:45 +0200	[thread overview]
Message-ID: <aJGNaQwnd6_A0Ppw@pks.im> (raw)
In-Reply-To: <xmqqwm7i527l.fsf@gitster.g>

On Mon, Aug 04, 2025 at 12:14:22PM -0700, Junio C Hamano wrote:
> Patrick Steinhardt <ps@pks.im> 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

  reply	other threads:[~2025-08-05  4:49 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-01 14:47 [PATCH 0/5] reftable: a couple of improvements for libgit2 Patrick Steinhardt
2025-08-01 14:47 ` [PATCH 1/5] reftable/writer: fix type used for number of records Patrick Steinhardt
2025-08-01 14:47 ` [PATCH 2/5] reftable/writer: drop Git-specific `QSORT()` macro Patrick Steinhardt
2025-08-01 14:47 ` [PATCH 3/5] reftable/stack: fix compiler warning due to missing braces Patrick Steinhardt
2025-08-01 19:19   ` Eric Sunshine
2025-08-04  6:03     ` Patrick Steinhardt
2025-08-04 19:14       ` Junio C Hamano
2025-08-05  4:49         ` Patrick Steinhardt [this message]
2025-08-12  4:18           ` Carlo Arenas
2025-08-12  9:27             ` Patrick Steinhardt
2025-08-12 14:37               ` Junio C Hamano
2025-08-01 14:47 ` [PATCH 4/5] reftable/stack: reorder code to avoid forward declarations Patrick Steinhardt
2025-08-01 14:47 ` [PATCH 5/5] reftable/stack: allow passing flags to `reftable_stack_add()` Patrick Steinhardt
2025-08-04  9:40 ` [PATCH v2 0/6] reftable: a couple of improvements for libgit2 Patrick Steinhardt
2025-08-04  9:40   ` [PATCH v2 1/6] reftable/writer: fix type used for number of records Patrick Steinhardt
2025-08-04  9:40   ` [PATCH v2 2/6] reftable/writer: drop Git-specific `QSORT()` macro Patrick Steinhardt
2025-08-04  9:40   ` [PATCH v2 3/6] reftable/stack: fix compiler warning due to missing braces Patrick Steinhardt
2025-08-04  9:40   ` [PATCH v2 4/6] reftable/stack: reorder code to avoid forward declarations Patrick Steinhardt
2025-08-11 19:10     ` Justin Tobler
2025-08-04  9:40   ` [PATCH v2 5/6] reftable/stack: allow passing flags to `reftable_stack_add()` Patrick Steinhardt
2025-08-11 19:34     ` Justin Tobler
2025-08-12  9:27       ` Patrick Steinhardt
2025-08-04  9:40   ` [PATCH v2 6/6] reftable/stack: handle outdated stacks when compacting Patrick Steinhardt
2025-08-11 20:04     ` Justin Tobler
2025-08-12  9:28       ` Patrick Steinhardt
2025-08-12  9:54 ` [PATCH v3 0/8] reftable: a couple of improvements for libgit2 Patrick Steinhardt
2025-08-12  9:54   ` [PATCH v3 1/8] reftable/writer: fix type used for number of records Patrick Steinhardt
2025-08-12  9:54   ` [PATCH v3 2/8] reftable/writer: drop Git-specific `QSORT()` macro Patrick Steinhardt
2025-08-12  9:54   ` [PATCH v3 3/8] reftable/stack: reorder code to avoid forward declarations Patrick Steinhardt
2025-08-12  9:54   ` [PATCH v3 4/8] reftable/stack: fix compiler warning due to missing braces Patrick Steinhardt
2025-08-12 16:51     ` Justin Tobler
2025-08-12  9:54   ` [PATCH v3 5/8] reftable/stack: allow passing flags to `reftable_stack_add()` Patrick Steinhardt
2025-08-12 16:59     ` Justin Tobler
2025-08-13  6:12       ` Patrick Steinhardt
2025-08-12  9:54   ` [PATCH v3 6/8] reftable/stack: handle outdated stacks when compacting Patrick Steinhardt
2025-08-12  9:54   ` [PATCH v3 7/8] reftable: don't second-guess errors from flock interface Patrick Steinhardt
2025-08-12 17:05     ` Justin Tobler
2025-08-12  9:54   ` [PATCH v3 8/8] refs/reftable: always reload stacks when creating lock Patrick Steinhardt
2025-08-12 17:12     ` Justin Tobler
2025-08-12 19:00   ` [PATCH v3 0/8] reftable: a couple of improvements for libgit2 Carlo Arenas
2025-08-13  6:11     ` Patrick Steinhardt
2025-08-13 14:23       ` Junio C Hamano
2025-08-13  6:25 ` [PATCH v4 " Patrick Steinhardt
2025-08-13  6:25   ` [PATCH v4 1/8] reftable/writer: fix type used for number of records Patrick Steinhardt
2025-08-13  6:25   ` [PATCH v4 2/8] reftable/writer: drop Git-specific `QSORT()` macro Patrick Steinhardt
2025-08-13  6:25   ` [PATCH v4 3/8] reftable/stack: reorder code to avoid forward declarations Patrick Steinhardt
2025-08-13  6:25   ` [PATCH v4 4/8] reftable/stack: fix compiler warning due to missing braces Patrick Steinhardt
2025-08-13  6:25   ` [PATCH v4 5/8] reftable/stack: allow passing flags to `reftable_stack_add()` Patrick Steinhardt
2025-08-13  6:25   ` [PATCH v4 6/8] reftable/stack: handle outdated stacks when compacting Patrick Steinhardt
2025-08-13  6:25   ` [PATCH v4 7/8] reftable: don't second-guess errors from flock interface Patrick Steinhardt
2025-08-13  6:25   ` [PATCH v4 8/8] refs/reftable: always reload stacks when creating lock Patrick Steinhardt
2025-08-13 14:38   ` [PATCH v4 0/8] reftable: a couple of improvements for libgit2 Justin Tobler

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aJGNaQwnd6_A0Ppw@pks.im \
    --to=ps@pks.im \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=sunshine@sunshineco.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).