[Top][All Lists]

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

Re: new files imported without new modules added

From: Eric Blake
Subject: Re: new files imported without new modules added
Date: Tue, 24 May 2011 10:54:20 -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/24/2011 10:45 AM, Sam Steingold wrote:
>> * Eric Blake <address@hidden> [2011-05-24 10:32:16 -0600]:
>>> I do _not_ want strerror_r.
>> Why not?
> because I copy away the strerror return value right away.

Are you multi-threaded?  Then you are suffering from a data race.  Are
you single threaded?  Then you shouldn't care if strerror had to use
strerror_r under the hood for its implementation (that's how glibc does
it), but you do have a (minor) point that configure is needlessly larger
in checking for strerror_r compliance.  Yes, strerror() is an
easier-to-use interface than sterror_r, but it is _only_ safe in
single-threaded programs.

Assuming you are single-threaded, your complaint is now: why does gnulib
take two files to implement sterror where it used to take one?  And the
answer is because when gnulib only used one file (that is, strerror.c
provided the gnulib replacement strings), then gnulib's perror and
strerror_r modules were not standards-compliant, whether or not you used
them.  Yes, we could make strerror.c and strerror_r.c both implement the
gnulib replacement strings, but that adds bulk.

So about the only other thing we can do is make both strerror.c and
strerror_r.c call into a third file that implements the gnulib
replacement strings, and thus make it so that strerror no longer
directly depends on strerror_r.c; patches welcome.

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]