bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: strerror vs. threads


From: Simon Josefsson
Subject: Re: strerror vs. threads
Date: Tue, 24 May 2011 23:30:39 +0200
User-agent: Gnus/5.110018 (No Gnus v0.18) Emacs/23.2 (gnu/linux)

Eric Blake <address@hidden> writes:

> On 05/24/2011 12:52 PM, Simon Josefsson wrote:
>>> POSIX explicitly allows strerror to use a static buffer, and that's
>>> _exactly_ what gnulib's implementation does on out-of-range input.
>>> Which means that "Unknown error (-1)" of thread 1 and "Unknown error
>>> (-2)" of thread 2 are calling sprintf on the same memory at the same
>>> time, and you will get indeterminate results.
>> 
>> Which begs the question why the error messages needs to be different for
>> different unknown errors?  Is that required by POSIX?
>
> Not required, but heavily recommended, and guaranteed by several common
> platforms.  And since "Error: " is much more confusing than "Error:
> Unknown error -1", especially at tracking down a bug at why errno is set
> to some weird value, it was worth documenting that we guarantee that
> behavior as one of the points of the gnulib strerror replacement.
>
> If you don't ever pass out-of-range errno values to strerror, then you
> probably don't care about thread-safety of the out-of-range buffer, but
> there is still the question of whether all existing implementations are
> thread-safe even on in-range errno values.

Maybe there could be a strerror_r-gnu and strerror_r-posix choice?  Or a
strerror_r-posixlean to just do the minimum required by POSIX.

For several of my projects that are libraries, any kind of thread
related code is bound to create portability problems.  (I haven't looked
in detail at the thread code here though, so I do not know how well it
handles systems without threads or how well it guesses the system thread
package.)

Further, having a strerror_r that returns the same string for two
different but equally bogus inputs is harmless to me -- even IF the code
path is triggered in the real world, and IF there actually is a problem,
the user won't be happier to see "Unknown error 4711" instead of
"Unknown error".  A developer is needed to resolve the problem anyway,
and they can add 'printf ("foo %d\n", errno);' if needed.

/Simon



reply via email to

[Prev in Thread] Current Thread [Next in Thread]