Bug#758911: libc6-dev: spurious sign-conversion warning for setrlimit, clang 3.5, _GNU_SOURCE
Package: libc6-dev
Version: 2.19-9
Severity: minor
Tags: upstream
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'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.
-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.14-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages libc6-dev depends on:
ii libc-dev-bin 2.19-9
ii libc6 2.19-9
ii linux-libc-dev 3.14.15-2
libc6-dev recommends no packages.
Versions of packages libc6-dev suggests:
pn glibc-doc <none>
ii manpages-dev 3.71-1
-- no debconf information
Reply to: