Bug#758911: libc6-dev: spurious sign-conversion warning for setrlimit, clang 3.5, _GNU_SOURCE

["Carlos O'Donell" <carlos@systemhalted.org>]

On Fri, Aug 22, 2014 at 3:23 PM, Zack Weinberg <zackw@panix.com> wrote:
> glibc changes the signature of setrlimit() when _GNU_SOURCE is defined, "to
> provide better error checking":
>
> extern int setrlimit (int, const struct rlimit *); // as specified by POSIX
> extern int setrlimit (__rlimit_resource_t, const struct rlimit *); //
> _GNU_SOURCE
>
> where __rlimit_resource_t is an enum with no negative values.  This causes some
> compilers (e.g. clang-3.5) to give spurious warnings for programs that pass
> non-constant values to setrlimit(), e.g.
>
> $ cat test.c
> #define _GNU_SOURCE
> #include <sys/resource.h>
> int foo(int rsrc, struct rlimit *rl)
> {
>   return setrlimit(rsrc, rl);
> }
> $ clang-3.5 -Wsign-conversion -c test.c
> test.c:5:20: warning: implicit conversion changes signedness: 'int' to
> '__rlimit_resource_t' (aka 'enum __rlimit_resource')
>       [-Wsign-conversion]
>   return setrlimit(rsrc, rl);
>          ~~~~~~~~~ ^~~~
>
> I don't think it's reasonable for me to have to work around this in my code,
> and indeed I don't see that there _is_ any workaround available to me in C.
> (Maybe in C++ some template black magic to extract "the type of the first
> argument to setrlimit"? Yech.)

I agree.

It isn't reasonable for users to have to work around this. Please file
a bug with clang and ask them to come work with with upstream glibc to
help provide better error checking and remove the spurious warning for
this case.

> I'm labeling this a libc bug rather than a clang bug because, if libc is going
> to deviate from the standard "to provide better error checking", it needs to
> ensure that standard-compliant code still works with no complaints, even at
> quite aggressive warning levels.

My opinion is that this is not a libc bug and I would suggest
debian-glibc close this bug. You deviated from the standard the second
you defined _GNU_SOURCE. If you want POSIX, but define _GNU_SOURCE,
and then complain it's not *exactly* POSIX then I don't see what we
did wrong. At best this is an enhancement: "Be more POSIX-like if I
define _GNU_SOURCE and happen to be using clang."

Cheers,
Carlos.