[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 8 Feb 2013 15:01:29 -0500
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: guard bug for strerror_r
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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
