[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" <sourceware-bugzilla@sourceware.org>]

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.