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

> 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); }
>         |                        ^~~

>>  (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.