[Bug libc/17307] New: Spurious -Wsign-conversion warning with clang-3.5, due to excessively clever glibc <sys/resource.h>

[Bug libc/17307] New: Spurious -Wsign-conversion warning with clang-3.5, due to excessively clever glibc <sys/resource.h>

[zackw at panix dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=17307

            Bug ID: 17307
           Summary: Spurious -Wsign-conversion warning with clang-3.5, due
                    to excessively clever glibc <sys/resource.h>
           Product: glibc
           Version: 2.19
            Status: NEW
          Severity: normal
          Priority: P2
         Component: libc
          Assignee: unassigned at sourceware dot org
          Reporter: zackw at panix dot com
                CC: drepper.fsp at gmail dot com

This test program ...

    #define _GNU_SOURCE
    #include <sys/resource.h>

    int spurious_sign_conversion_warning(int r, struct rlimit *l)
    {
        return setrlimit(r, l);
    }

... produces a spurious -Wsign-conversion warning when compiled against
recent GNU libc's headers:

    $ clang-3.5 -Wsign-conversion -c setrlimit.c 
    setrlimit.c:6:22: warning: implicit conversion changes signedness: 'int' to
          '__rlimit_resource_t' (aka 'enum __rlimit_resource')
[-Wsign-conversion]
        return setrlimit(r, l);
               ~~~~~~~~~ ^
    1 warning generated.

The problem is this construct in <sys/resource.h>:

    /* The X/Open standard defines that all the functions below must use
       `int' as the type for the first argument.  When we are compiling with
       GNU extensions we change this slightly to provide better error
       checking.  */
    #if defined __USE_GNU && !defined __cplusplus
    typedef enum __rlimit_resource __rlimit_resource_t;
    typedef enum __rusage_who __rusage_who_t;
    typedef enum __priority_which __priority_which_t;
    #else
    typedef int __rlimit_resource_t;
    typedef int __rusage_who_t;
    typedef int __priority_which_t;
    #endif

`enum __rlimit_resource` has no negative values and is therefore (I presume)
assigned an unsigned type, triggering the warning.

I don't think I should have to work around this in my code.  X/Open says the
type of `setrlimit`'s first argument is `int`, therefore `RLIM_*` constants
should be passed around in `int` variables.  Moreover, I don't see that there
*is* any workaround available to me in C that wouldn't harm portability to
other systems.  (A portable program can reasonably want to define `_GNU_SOURCE`
in order to take advantage of specific glibc features when available.)

I initially filed this as a bug with Debian's glibc (
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=758911 ) and was asked to
file an upstream clang bug inviting them to work with upstream glibc to resolve
this in a mutually satisfactory way.  That bug report is
http://llvm.org/bugs/show_bug.cgi?id=20742 .  I am also filing this with you,
because I think this is as much libc's fault as it is clang's -- defining
`_GNU_SOURCE` should *not* change the signature of standardized functions in a
way that is observable to correct code.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/17307] Spurious -Wsign-conversion warning with clang-3.5, due to excessively clever glibc <sys/resource.h>

[carlos at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=17307

Carlos O'Donell <carlos at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |carlos at redhat dot com

--- Comment #1 from Carlos O'Donell <carlos at redhat dot com> ---
The first question I have is: Does this trigger a gcc warning with new enough
gcc. If it does then we're in trouble and likely need to remove our cleverness.
If it doesn't then it would be good to talk with clang developers to see if we
can do some kind of whitelist to make this all work. The implementation is
certainly OK to collude on these things as long as we all move forward in the
right direction and can agree on that direction.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/17307] Spurious -Wsign-conversion warning with clang-3.5, due to excessively clever glibc <sys/resource.h>

[zackw at panix dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=17307

--- Comment #2 from Zack Weinberg <zackw at panix dot com> ---
gcc-4.9's -Wsign-conversion does not complain.  I think this may actually be a
lacuna in gcc's implementation of those warnings, because *this* program...

#include <sys/resource.h>
#include <stdio.h>
#include <type_traits>

int main(void)
{
    printf("%d %d\n",
           std::is_signed<enum __rlimit_resource>::value,
           std::is_signed<
               std::underlying_type<
                   enum __rlimit_resource>::type>::value);
    return 0;
}

... prints "0 0" when compiled with either clang++3.5 or g++4.9.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/17307] Spurious -Wsign-conversion warning with clang-3.5, due to excessively clever glibc <sys/resource.h>

[bugdal at aerifal dot cx]

https://sourceware.org/bugzilla/show_bug.cgi?id=17307

Rich Felker <bugdal at aerifal dot cx> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bugdal at aerifal dot cx

--- Comment #3 from Rich Felker <bugdal at aerifal dot cx> ---
The "cleverness" is just wrong and should be removed. It makes it impossible to
use function pointers to setrlimit since they have the wrong type.
(Technically, gcc may let you get by with just a warning when the function
pointer type mismatches, but it's invalid C and should be an error.)

-- 
You are receiving this mail because:
You are on the CC list for the bug.