Re: strerror vs. threads

[Eric Blake]

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
strerror_r.

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

signature.asc
Description: OpenPGP digital signature