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

[Carlos O'Donell]

On 3/25/25 3:29 PM, Florian Weimer wrote:
> * Collin Funk:
> 
>> Florian Weimer <fweimer@redhat.com> writes:
>>
>>> This change alters the type of all enum constants from int to unsigned
>>> int.  Should we keep the type of the other constants?  Or use INT_MIN
>>> (expanded) for MS_NOUSER?
>>
>> Since mount(2) expects an unsigned long flags, I feel like changing it
>> to unsigned should be fine. Since the flags are meant to be OR'd
>> together, I don't think anyone should be using operators like ==, which
>> might trigger -Wsign-compare or something like that.
> 
> I'm not sure if there are any good options here.
> 
> The type unsigned long is clearly nominal only, the kernel has to
> disregard the upper 32 bits if they exist due to the current sign
> extension.
> 
> I looked at previous examples, and we generally use 1U << 31 instead of
> -2147483647 - 1.  This commit made all enum constants unsigned, too:
> 
> commit 4920765eb417431261367bf65f1a8a5ffb78baf7
> Author: Ulrich Drepper <drepper@gmail.com>
> Date:   Wed Dec 21 22:14:05 2011 -0500
> 
>      Define EPOLLONESHOT and EPOLLET using unsigned values
> 
> So there is some precedent for what you are doing here.

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

Before C23 they are.

As of C23 they are not (which allows underlying type specification).

Example:
test.c:5:14: error: ISO C restricts enumerator values to range of ‘int’ before C23 [-Wpedantic]
     5 |    val3    = 0xFFFFFFF0
       |              ^~~~~~~~~~

-- 
Cheers,
Carlos.