[Bug libc/1890] strerror() unnecessarily non thread-safe

["stefan dot puiu at gmail dot com" <sourceware-bugzilla@sourceware.org>]

------- Additional Comments From stefan dot puiu at gmail dot com  2005-11-23 07:35 -------
Well, the glibc info file says: 

"This function `strerror_r' is a GNU extension"

So either the documentation is wrong, or the function isn't conforming to POSIX
- I don't have a copy of the standard to check. This document: 
http://www.opengroup.org/rtforum/uploads/40/7319/POSIX_and_Linux_Application_Compatibility_v0.92_released_22_April_05.pdf

says that POSIX strerror_r() returns an int, the GNU one returns a char*; OTOH,
as I said before, other platforms have thread-safe strerror() (Solaris 8 has it,
HP-UX 11i has it), and some (Solaris 8, for example) don't even have
strerror_r() *at all*. Thus, using strerror_r() breaks portability anyway. Not
to mention that if you google for "strerror_r on linux" you'll find posts by
users that were confused by the fact that the function didn't even use the
supplied buffer (check out
http://lists.gnu.org/archive/html/autoconf/2004-12/msg00079.html or
http://www.openldap.org/lists/openldap-bugs/200404/msg00191.html). In my
opinion, requiring a buffer argument that you *might* use in some weird
circumstances is bad design. 

The "extra info" you talk about can be provided by simply printing out the errno
value. If any applications rely on errnos outside the normal range, they should
do this anyway. 

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|WONTFIX                     |


http://sourceware.org/bugzilla/show_bug.cgi?id=1890

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.