[Top][All Lists]
[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
- Re: disabling multithreading, (continued)
- Re: new files imported without new modules added, Sam Steingold, 2011/05/24
- Re: new files imported without new modules added, Eric Blake, 2011/05/24
- Re: new files imported without new modules added, Sam Steingold, 2011/05/24
- Re: new files imported without new modules added, Eric Blake, 2011/05/24
- Re: new files imported without new modules added, Sam Steingold, 2011/05/24
- strerror vs. threads [was: new files imported without new modules added], Eric Blake, 2011/05/24
- Re: strerror vs. threads [was: new files imported without new modules added], Simon Josefsson, 2011/05/24
- Re: strerror vs. threads, Eric Blake, 2011/05/24
- Re: strerror vs. threads, Paul Eggert, 2011/05/24
- Re: strerror vs. threads,
Simon Josefsson <=
- Re: strerror vs. threads, Eric Blake, 2011/05/24
- Re: strerror vs. threads, Simon Josefsson, 2011/05/25
- Re: strerror vs. threads, Eric Blake, 2011/05/25
- coping with conflicting strerror_r signatures [was: strerror vs. threads], Eric Blake, 2011/05/25
- Re: strerror vs. threads [was: new files imported without new modules added], Sam Steingold, 2011/05/24
- Re: strerror vs. threads [was: new files imported without new modules added], Eric Blake, 2011/05/24
- [PATCH 1/2] perror: call strerror_r directly, Eric Blake, 2011/05/24
- [PATCH 2/2] strerror: drop strerror_r dependency, Eric Blake, 2011/05/24
- Re: new files imported without new modules added, Bruno Haible, 2011/05/24
- Re: new files imported without new modules added, Eric Blake, 2011/05/24