From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10847 invoked by alias); 23 Nov 2005 07:35:55 -0000 Received: (qmail 10836 invoked by uid 48); 23 Nov 2005 07:35:52 -0000 Date: Wed, 23 Nov 2005 07:35:00 -0000 Message-ID: <20051123073552.10835.qmail@sourceware.org> From: "stefan dot puiu at gmail dot com" To: glibc-bugs@sources.redhat.com In-Reply-To: <20051119151517.1890.stefan.puiu@gmail.com> References: <20051119151517.1890.stefan.puiu@gmail.com> Reply-To: sourceware-bugzilla@sourceware.org Subject: [Bug libc/1890] strerror() unnecessarily non thread-safe X-Bugzilla-Reason: CC Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sourceware.org X-SW-Source: 2005-11/txt/msg00111.txt.bz2 List-Id: ------- 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.