Re: [PATCH v3 02/14] odb: fix flags parameter to be unsigned

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 22, 2026, 15:41 UTC
Message-ID: <xmqqcy31pscg.fsf@gitster.g>
In-Reply-To: <aXFosXv328ZPjlcw@nand.local>

Taylor Blau <me@ttaylorr.com> writes:

> I agree with you that we should be using an enum in these cases over
> unsigned for the reasons you suggest. I've stumbled over this in the
> past, so perhaps this is worth adding to the CodingGuidelines?

I am OK with declaring our preference of "enum" over "#define"d constants. The only two minor hesitation I have against the use of "enum", especially for bitset but not for enumeration, are that

 (1) enum gives a false sense of type safety to casual coders. If I
     have two enum types and pass one to as a parameter to a
     function that expects the other one, would the compiler help me
     catch that as a potential mistake?  -Wenum-conversion is not
     enabled even with -Wall so I am assuming that the compiler
     folks fells that it is not reliable enough.

 (2) it is not easy to force an enum type to be unsigned, unless you
     are at C23 or above.  If shifting enums are warned by the
     compilers by default, I wouldn't worry about it, but use of
     unsigned is more explicit in this regard.

Use of enum does help debuggers, as gcc figures out that three and tres are both (ONEBIT | TWOBIT) when asked to print it in the following snippet.

    enum bits {
            ONEBIT = (1 << 0),
            TWOBIT = (1 << 1),
    };

    int main(int ac, char **av)
    {
            enum bits one = ONEBIT;
            enum bits two = TWOBIT;
            enum bits three = one | two;
            enum bits tres = 3;
            ...