Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.