From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/2752 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: guard bug for strerror_r Date: Fri, 8 Feb 2013 15:01:29 -0500 Message-ID: <20130208200129.GK20323@brightrain.aerifal.cx> References: <1360342098.2983.360.camel@eris.loria.fr> <20130208165542.GW6181@port70.net> <1360344600.2983.365.camel@eris.loria.fr> <20130208100125.0d6bf697.idunham@lavabit.com> <20130208185918.GJ20323@brightrain.aerifal.cx> <1360353231.2983.382.camel@eris.loria.fr> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1360353701 26137 80.91.229.3 (8 Feb 2013 20:01:41 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 8 Feb 2013 20:01:41 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-2753-gllmg-musl=m.gmane.org@lists.openwall.com Fri Feb 08 21:02:02 2013 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1U3u94-0003Vx-7n for gllmg-musl@plane.gmane.org; Fri, 08 Feb 2013 21:02:02 +0100 Original-Received: (qmail 15926 invoked by uid 550); 8 Feb 2013 20:01:42 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 15913 invoked from network); 8 Feb 2013 20:01:42 -0000 Content-Disposition: inline In-Reply-To: <1360353231.2983.382.camel@eris.loria.fr> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:2752 Archived-At: On Fri, Feb 08, 2013 at 08:53:51PM +0100, Jens Gustedt wrote: > Hello > > Am Freitag, den 08.02.2013, 13:59 -0500 schrieb Rich Felker: > > > #if defined(__GLIBC__) && defined(__USE_GNU) > > the __GLIBC__ thing seems to work for my case, now. strerror_r seems > to be the only interface where they use the same name with a different > interface, so I'll bug something around that. Yes, that and basename are the only interfaces I'm aware of with incompatible GNU versions. I actually opened a related bug tracker issue: http://sourceware.org/bugzilla/show_bug.cgi?id=15124 > > I would simply avoid _ever_ using strerror_r on GNU systems. On any > > modern GNU or POSIX 2008 conforming system, you have the vastly > > superior strerror_l function. It does not require you to provide a > > buffer, and it's thread-safe (the buffer returned is either immutable > > static or thread-local). The logic I'd recommend is: > > > > #if _POSIX_VERSION >= 200809L || defined(__GLIBC__) > > /* use strerror_l */ > > #else > > /* use strerror_r and assume POSIX version of it */ > > #endif > > Hm, I have a relatively recent system (ubuntu) and there is no trace > of strerror_l in the documentation, even in their "POSIX" man page. It's part of the "xlocale" set of interfaces that seem to have originated with glibc or maybe Sun, and later made it into POSIX 2008. It allows you to pass a locale_t argument to get the results in a non-default locale, but you can instead just request the current locale. Honestly I don't know why POSIX didn't just require strerror itself to be thread-safe, but at the time it was probably an "unacceptable burden" to at least one implementation and then the issue was never revisited because strerror_r already existed. > And I actually use this in P99 to provide the C11 Annex K interface > strerror_s, which is much closer to strerror_r than strerror_l. Well, > we now have Are you sure this is the best interface to provide to applications? I'd instead provide a thread-safe interface with an interface identical to strerror, since that's by far the easiest to use. If on the other hand you want to provide Annex K in principle, that's another matter, but there's a fairly large portion of it that can't be provided portably on top of an existing libc (mainly the scanf or printf stuff, I think). > strerror C, POSIX > strerror_r POSIX > strerror_l POSIX > strerror_s C > > superbe. Again a case where a liaison between the C committee and the > POSIX could have helped. The problem seems to be just that C didn't have threads (and thus no need for strerror_r or strerror_l) until C11. Rich