[Top][All Lists]

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

Re: strerror vs. threads

From: Eric Blake
Subject: Re: strerror vs. threads
Date: Wed, 25 May 2011 08:32:34 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110428 Fedora/3.1.10-1.fc14 Lightning/1.0b3pre Mnenhy/0.8.3 Thunderbird/3.1.10

On 05/25/2011 02:59 AM, Simon Josefsson wrote:
>> Therefore, I'm afraid that the more portable choice is to consistently
>> stick to the standard definition, rather than the GNU definition, even
>> if the GNU definition is slightly easier to use.
> Yes.  What we'd really like is a dependency scheme that can express
> something like "strerror_r-gnu | strerror_r-posix"...

But that _still_ leaves us with the issue of how do you know which
signature of strerror_r you are calling?  Remember, glibc
strerror_r(EACCES,buf,len) leaves buf untouched - you are expected to
use the returned pointer; but XPG strerror_r(EACCES,buf,len) returns an
int which is almost guaranteed to be fatal if you dereference it as a char*.

If glibc were to change GNU strerror_r to _always_ populate buf, in
addition to the return string, then you could blindly call either
variant of strerror_r and just ignore the return value; the only
remaining problem is making sure you provide a large enough buffer for
any resulting string, since you no longer have error checking to tell if
buf got truncated.  I guess it's worth a shot asking Uli if he'll make
that change in glibc (since he already changed __xpg_strerror_r to
populate buf).

>> Since the whole point of strerror_r is to get an error message to be
>> worth printing, it's easier to stick with the POSIX recommendations
>> that the message be usable regardless of error, even though POSIX (for
>> backwards compatibility reasons) chose to permit weaker
>> implementations.
> ..although if it comes with the portability hurdles of threads, I'm not
> convinced it will be "easier" for everyone in the long run.

Which somewhat goes back to my question of whether using the strerror_r
in a single-thread program should drag in the lock module, or if it
acceptable to conditionally compile in the lock code in strerror_r.c if
lock is present but otherwise skip locking, under the assumption that
any multi-threaded program is explicitly using locks in addition to

Or maybe make a 'strerror_r-posix-simple' that is not thread-safe, which
does not depend on 'lock', and 'strerror_r-posix' depends on
'strerror_r-posix-simple' and on 'lock', so that the default module name
is thread-safe, and you have to ask for the longer module name if you
explicitly don't care about locking but want to use the reentrant
interface.  Then again, if you are single-threaded, then 'strerror' is
easier to use than 'strerror_r'.  So I've somewhat convinced myself that
things are fine as they are - strerror_r-posix should drag in 'lock',
and we don't need a single-threaded variant there.

Eric Blake   address@hidden    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

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