All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Han-Wen Nienhuys <hanwen@google.com>
Cc: Patrick Steinhardt <ps@pks.im>, git <git@vger.kernel.org>
Subject: Re: flags types/names
Date: Mon, 31 Jan 2022 09:13:15 -0800	[thread overview]
Message-ID: <xmqqbkzrkevo.fsf@gitster.g> (raw)
In-Reply-To: <CAFQ2z_M_SXENMU6Y3Evrz9-G_+pqjd-zPQiZjnA_y2hvb+Egkw@mail.gmail.com> (Han-Wen Nienhuys's message of "Mon, 31 Jan 2022 10:50:16 +0100")

Han-Wen Nienhuys <hanwen@google.com> writes:

> My questions:
>
> * am I the only one who struggles with the different flavor of `flags` ?

Probably no.

> * if no, what should be done about this? Maybe
>
>   typedef unsigned int ref_flags;
>   #define REF_IS_SYMREF 0x1
>   char *refs_resolve_ref_unsafe(const char *refname, ref_flags *flags, ... );
>
> or
>
>   typedef enum ref_flags {
>      REF_IS_SYMREF = 0x1,
>   };
>   char *refs_resolve_ref_unsafe(const char *refname, enum ref_flags
> *flags, ... );

It is very good to use symbolic constants implemented either as C
preprocessor macros or enums, I would think.

However, I am not enthused to see typedefs; I've never seen multiple
typedefs of the same integral type did anything useful in C.  Perhaps
things are different in the C++ land, but we do not live there.

> A somewhat related gripe is that some code uses `int flags` and other
> code uses `unsigned flags`. It would be great to standardize this.

I agree.  Unless there is very compelling reason to single out the
topmost bit and treat it as special, a set of flag bits should be
"unsigned".

  reply	other threads:[~2022-01-31 17:13 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-24 19:39 What's cooking in git.git (Jan 2022, #07; Mon, 24) Junio C Hamano
2022-01-25 19:45 ` Submodule UX overhaul update (was: What's cooking in git.git (Jan 2022, #07; Mon, 24)) Emily Shaffer
2022-01-26 14:09   ` Ævar Arnfjörð Bjarmason
2022-01-26 17:27     ` Emily Shaffer
2022-01-26 15:16   ` Kaartic Sivaraam
2022-01-26 16:35   ` Atharva Raykar
2022-01-26 17:43     ` Emily Shaffer
2022-01-26 17:50     ` Glen Choo
2022-01-28  7:40 ` ps/avoid-unnecessary-hook-invocation-with-packed-refs (Was: " Patrick Steinhardt
2022-01-28 21:14   ` ps/avoid-unnecessary-hook-invocation-with-packed-refs Junio C Hamano
2022-01-31  9:50     ` flags types/names (was: ps/avoid-unnecessary-hook-invocation-with-packed-refs) Han-Wen Nienhuys
2022-01-31 17:13       ` Junio C Hamano [this message]
2022-01-28 22:31 ` What's cooking in git.git (Jan 2022, #07; Mon, 24) brian m. carlson
2022-02-04  0:27   ` Junio C Hamano
2022-02-04 17:27     ` René Scharfe
2022-02-02 11:28 ` ab/auto-detect-zlib-compress2 (was: What's cooking in git.git (Jan 2022, #07; Mon, 24)) Ævar Arnfjörð Bjarmason

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=xmqqbkzrkevo.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=hanwen@google.com \
    --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.