[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130208203825.GM20323@brightrain.aerifal.cx>
Date: Fri, 8 Feb 2013 15:38:25 -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 09:31:11PM +0100, Jens Gustedt wrote:
> And, also I think that even before the _r version would have been a
> good thing. I think the _r stands for reentrant, and for a function
> that you would typically like to use in error or signal handlers, this
> is a nice feature.
Yes, but unfortunately the _r's and use of the word "reentrant" in
issue 6 and earlier were all wrong; they used it to mean thread-safe,
not reentrant. None of the _r functions are required to be reentrant.
The term POSIX uses for reenatrant is "async-signal-safe", and
strerror_r is not async-signal-safe. This is not just a theoretical
limitation; in practice, most implementations probably fail to be
reentrant due to use of a mutex protecting access to the current
locale data.
If/when musl adds any locale state that would need synchronization, I
think our strerror should still be async-signal-safe, either using
musl's recursive mutex (which is also a reentrant mutex) or lock-free
atomic logic.
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.
