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 -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140822192315.11720.26219.report...@othila.ece.cmu.edu