All of lore.kernel.org
 help / color / mirror / Atom feed
From: Justin Tobler <jltobler@gmail.com>
To: Patrick Steinhardt <ps@pks.im>
Cc: "Junio C Hamano" <gitster@pobox.com>,
	"René Scharfe" <l.s.r@web.de>,
	git@vger.kernel.org
Subject: Re: [PATCH 3/3] odb: drop gaps in object info flag values
Date: Mon, 9 Feb 2026 14:32:33 -0600	[thread overview]
Message-ID: <aYpBH2eSjArsM_To@denethor> (raw)
In-Reply-To: <aXhbXQo6taM33m-1@pks.im>

On 26/01/27 07:29AM, Patrick Steinhardt wrote:
> Unfortunately, the other callsite wouldn't see a warning because we pass
> an integer constant, and the compiler doesn't complain about that at
> all. It also falls apart once you start to OR multiple flags together.

I guess we could have enum values to each of the combinations that get
used together, but that problably isn't a great idea if we use many
different combinations and may not be good in the long term.

> It would be great if there was a way to tell the compiler that a given
> flags field expects only enum values so that it could always warn about
> misuse. But I'm not aware of any way to do this.

I agree with the sentiment. Passing a combination of enum values as
unsigned flags is a bit fragile and in some ways feels like it defeats
the point of using enums to begin with. Also when using a function that
accepts flags, it is not always immediately obvious which set of flags
are expected.

> We could of course start to take a more heavy-handed approach and always
> accept an options struct instead. E.g.
> 
>     struct odb_read_object_info_options {
>             unsigned lookup_replace : 1,
>                      quick : 1,
>                      skip_fetch_object : 1,
>                      for_prefetch : 1,
>                      die_if_corrupt : 1;
>     };
> 
> That would give us full type safety, and it would be impossible to
> misuse without getting a compiler warning. Furthermore, with designated
> initializers it wouldn't be _that_ awful to use:
> 
> 	if (!odb_read_object_extended(ctx->repo->objects, &list->oid[i],
> 				      (struct odb_read_object_info_options) {
> 		.skip_fetch_object = 1,
> 	}) < 0) {
> 		die("...");
> 	}
> 
> But I wouldn't exactly call it ergonomic, either.

This would certainly be the most safe option, but I also agree that it
not particually ergonomic. I'm not sure it's worth going this far as
long as it's documented/easy-to-find the corresponding set of flags.

> So I'm not sure whether this partial protection would be worth it, but
> if you think it is I'm happy to reroll.

I think this version of series is good and doesn't need a reroll.

Thanks,
-Justin

  reply	other threads:[~2026-02-09 20:32 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-26 12:17 [PATCH 0/3] Small fixups for `OBJECT_INFO` flags Patrick Steinhardt
2026-01-26 12:17 ` [PATCH 1/3] builtin/backfill: fix flags passed to `odb_has_object()` Patrick Steinhardt
2026-01-26 20:17   ` Derrick Stolee
2026-01-26 21:07     ` Junio C Hamano
2026-02-09 19:57   ` Justin Tobler
2026-02-10  9:24   ` Karthik Nayak
2026-02-10  9:32     ` Karthik Nayak
2026-01-26 12:17 ` [PATCH 2/3] builtin/fsck: " Patrick Steinhardt
2026-02-09 20:04   ` Justin Tobler
2026-01-26 12:17 ` [PATCH 3/3] odb: drop gaps in object info flag values Patrick Steinhardt
2026-01-26 16:58   ` Junio C Hamano
2026-01-26 18:02     ` René Scharfe
2026-01-26 18:13       ` Junio C Hamano
2026-01-27  6:29         ` Patrick Steinhardt
2026-02-09 20:32           ` Justin Tobler [this message]
2026-02-09 20:18   ` Justin Tobler
2026-01-26 16:28 ` [PATCH 0/3] Small fixups for `OBJECT_INFO` flags Junio C Hamano
2026-02-12  6:59 ` [PATCH v2 0/5] " Patrick Steinhardt
2026-02-12  6:59   ` [PATCH v2 1/5] builtin/backfill: fix flags passed to `odb_has_object()` Patrick Steinhardt
2026-02-12  6:59   ` [PATCH v2 2/5] builtin/fsck: " Patrick Steinhardt
2026-02-12  6:59   ` [PATCH v2 3/5] odb: drop gaps in object info flag values Patrick Steinhardt
2026-02-12  6:59   ` [PATCH v2 4/5] odb: convert object info flags into an enum Patrick Steinhardt
2026-02-12  6:59   ` [PATCH v2 5/5] odb: convert `odb_has_object()` " Patrick Steinhardt

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=aYpBH2eSjArsM_To@denethor \
    --to=jltobler@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=l.s.r@web.de \
    --cc=ps@pks.im \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.