[PATCH] linux: Fix integer overflow warnings when including <sys/mount.h> [BZ #32708]

[Carlos O'Donell]

On 3/25/25 3:42 PM, Collin Funk wrote:
> Florian Weimer <fweimer@redhat.com> writes:
> 
>> I believe unsigned enum types are still a GNU extension, but maybe
>> <sys/mount.h> isn't expected to be processed with compilers without such
>> extensions.
> 
> I don't think that unsigned enums are a GNU extension. In C99 section
> 6.7.2.2 [1]:

I think the correct question to ask is if the value is representable
without an extension.

You quote 6.7.2.2 # 4

>      Each enumerated type shall be compatible with char, a signed integer
>      type, or an unsigned integer type. The choice of type is
>      implementation-defined, 110) but shall be capable of representing the
>      values of all the members of the enumeration. The enumerated type is
>      incomplete until after the } that terminates the list of enumerator
>      declarations.

There is an earlier 6.7.2.2 # 2 (just saw Florian post the same)

        The expression that defines the value of an enumeration constant
        shall be an integer constant expression that has a value representable
        as an int.

Which limits the value representable.
  
> And subscript 110:
> 
>      An implementation may delay the choice of which integer type until
>      all enumeration constants have been seen.

While this is true, the current value in the sign bit can't be represented
and so is invalid ISO C before C23 unless you have an extension.

> This definition taken from Gnulib is a good demonstration of this:
> 
>      typedef enum
>      {
>        _Bool_must_promote_to_int = -1,
>        false = 0,
>        true = 1
>      } _Bool;
> 
> Without _Bool_must_promote_to_int the compiler is free to chose
> 'unsigned int' as the type for the enum, which is unwanted in this case.

In summary:

- The current value of various header constants of the form 1U << 31 are
   technically not representable without a compiler language extension
   because before C23 this wasn't representable.

- I still think using "1U << 31" is the clearest possible solution and
   follows established precedent. You need a compiler that supports
   unsigned enums and the full representable range to compile code in
   the ecosystem.

-- 
Cheers,
Carlos.