From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.4.1) Gecko/20031114 Description of problem: The prototype for strerror_r given in the manual page and the one appearing in /usr/include/string.h don't agree. man strerror_r gives: int strerror_r(int errnum, char *buf, size_t n); whereas 'fgrep strerror_r /usr/include/*' gives: /usr/include/string.h:extern char *strerror_r (int __errnum, char *__buf, size_t __buflen) __THROW; So, does strerror_r return an int or a char *? Version-Release number of selected component (if applicable): glibc-2.3.2-101.4 How reproducible: Always Steps to Reproduce: 1. man strerror_r 2. fgrep strerror_r /usr/include/* 3. Actual Results: Prototypes differ Expected Results: Prototypes should agree Additional info: None
glibc strerror_r returns char * (and uses the buffer only for some errors, for others it doesn't modify the buffer at all and just returns a string literal (and has behaved this way at least since 1993). It seems Unix 2003 recently added strerror_r with conflicting prototype and behaviour (there has been no strerror_r in Unix 98) and seems the man page describes Unix 2003 behaviour (while info strerror_r describes the glibc behaviour). I think glibc probably needs to change to match Unix 2003 and keep compatibility via symbol versioning, but am not sure how many programs will be broken by that change.
In FC2 glibc (2.3.3-27), if you build with -D_XOPEN_SOURCE=600 or -D_POSIX_SOURCE=200112L, strerror_r returning int will be used, otherwise the GNU variant.