Red Hat Bugzilla – Bug 118793
strerror_r prototype inconsistency
Last modified: 2007-11-30 17:10:38 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.4.1)
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):
Steps to Reproduce:
1. man strerror_r
2. fgrep strerror_r /usr/include/*
Actual Results: Prototypes differ
Expected Results: Prototypes should agree
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.