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

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

[stefan dot puiu at gmail dot com]

Because of some confusing information in the strerror() manual page, I decided
to check the glibc-2.3.6 source and see for myself, and was dissapointed to see
how strerror_r() (sysdeps/generic/_strerror.c) and strerror()
(string/strerror.c) are implemented. The only reason strerror() is not thread
safe is because it insists keeping a global buffer around, which it mallocs when
needed and then fills it in when it gets called with an invalid errno, with a
string like "Unknown error: <errno>". I would say this is a useless
complication, buys you nothing (you can examine the value without strerror()
supplying it back to you in a buffer), and forces people to use the non-POSIX
strerror_r() (which returns a char*), which only uses the supplied buffer when
the aforementioned situation occurs, further confusing people. 

I suggest changing strerror so that it simply returns "Unknown error" when an
invalid errno is supplied, and deprecating strerror_r. I can provide a patch if
needed. 

Note: both Solaris and HP-UX have thread-safe strerror() functions, so this will
ease the work of people developing applications for multiple Unices.

-- 
           Summary: strerror() unnecessarily non thread-safe
           Product: glibc
           Version: 2.3.6
            Status: NEW
          Severity: normal
          Priority: P2
         Component: libc
        AssignedTo: drepper at redhat dot com
        ReportedBy: stefan dot puiu at gmail dot com
                CC: glibc-bugs at sources dot redhat dot com


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.

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

[drepper at redhat dot com]

------- Additional Comments From drepper at redhat dot com  2005-11-22 18:13 -------
strerror_r is the POSIX function to use.  Everything else is incompatible in
multi-threaded environment.  Additionally, the extra info provided by strerror
for unknown errors is crucial in some situations, it is completely unacceptable
to return a generic string.  There will be no change.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         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.

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

[stefan dot puiu at gmail dot com]

------- 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.

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

[drepper at redhat dot com]

------- Additional Comments From drepper at redhat dot com  2005-11-23 08:31 -------
Dammit, don't reopen bugs, especially if  you are clueless.

glibc provides two strerror_r definitions.  Just pick the stupid POSIX
definition if you must.

There will be no change.  Period.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         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.

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

[stefan dot puiu at gmail dot com]

------- Additional Comments From stefan dot puiu at gmail dot com  2005-11-23 09:15 -------

Funny thing you insist keeping a broken design, breaking compatibility (check
out the autoconf wizardry required to be portable about strerror right now), all
that for some stupid "extra info", and still call *me* clueless. 

Have a nice day. 

-- 


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.

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

[stefan dot puiu at gmail dot com]

------- Additional Comments From stefan dot puiu at gmail dot com  2005-11-23 09:25 -------
Oh, and about "picking the stupid definition", I specifically pointed you to a
post on the autoconf mailing list. Here's a quote: 


"You would be best served by using configure to learn how the default strerror_r
behaves and adapting your code to suit.

You don't want to force -D_XOPEN_SOURCE=600 on all systems because behavior when
the system does not support this level is undefined. In my experience, headers
on some systems fail miserably if you specify an _XOPEN_SOURCE value greater
than what they were designed to expect. Using -D_XOPEN_SOURCE=500 is reasonably
safe on most (but not all) systems.

Trying to force the headers to behave a particular way seems to be a lost cause.
After trying this approach for a number of months, I finally realized that
relying on default behavior worked best."

-- 


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.