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

[Junio C Hamano <gitster@pobox.com>]

Jeff King <peff@peff.net> writes:

> I don't think there's any disagreement over using enums in general. It's
> just a question of what type to declare in function interfaces.
>
>>  (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.
>
> It is enabled with -Wextra, which we turn on with DEVELOPER=1. I think
> gcc will catch the most obvious mismatches like:
>
>   enum one { FOO };
>   enum two { BAR };
>   void func(enum one value);
>   void doit(void) { func(BAR); }
>
> which yields:
>
>   $ gcc -c -Wall -Wextra foo.c
>   foo.c: In function ‘doit’:
>   foo.c:4:24: warning: implicit conversion from ‘enum two’ to ‘enum one’ [-Wenum-conversion]
>       4 | void doit(void) { func(BAR); }
>         |                        ^~~

This is good.  I think we just saw a potential use of this feature
in Patrick's topic to turn a #define to an enum in <odb.h>.

>>  (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.
>
> Do we need to force unsignedness for bit-flags? The compiler will use a
> type that is sufficiently large for the enum values defined, and I would
> not expect anybody to shift them.

Yes, as long as nobody shifts, it does not matter.  It's just not
having to worry about it trumps having to declare that we would
immediately notice if anybody does something strange like that ;-)