[Top][All Lists]

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

Re: [PATCH] strerror_r: enforce POSIX recommendations

From: Eric Blake
Subject: Re: [PATCH] strerror_r: enforce POSIX recommendations
Date: Mon, 23 May 2011 14:23:37 -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/21/2011 12:09 PM, Bruno Haible wrote:
> Eric Blake wrote:
>>  2011-05-20  Eric Blake  <address@hidden>
>> +    strerror_r: enforce POSIX recommendations
>> +    * lib/strerror_r.c (safe_copy): New helper method.
>> +    (strerror_r): Guarantee a non-empty string.
>> +    * tests/test-strerror_r.c (main): Enhance tests to incorporate
>> +    recent POSIX rulings and to match our strerror guarantees.
>> +    * doc/posix-functions/strerror_r.texi (strerror_r): Document this.
> This looks good, except one part:
>> @@ -436,9 +448,16 @@ strerror_r (int errnum, char *buf, size_t buflen)
>>      {
>>        extern int __xpg_strerror_r (int errnum, char *buf, size_t buflen);
>> +      *buf = '\0';
>>        ret = __xpg_strerror_r (errnum, buf, buflen);
>>        if (ret < 0)
>>          ret = errno;
>> +      if (!*buf)
>> +        {
>> +          /* GNU strerror_r always returns a thread-safe untruncated
>> +             string; copy that into our buf.  */
>> +          safe_copy (buf, buflen, strerror_r (errnum, buf, buflen));
>> +        }
>>      }
> Here I would prefer to use __xpg_strerror_r a second time, with a
> stack-allocated buffer of size 256.

But that _won't work_ with glibc 2.13, at least for the EINVAL case (it
works for the ERANGE case, though).  Ulrich patched things last week to
always populate buf, but prior to last week,
__xpg_strerror_r(-1,buf,buflen) left buf untouched, so we _have_ to fall
back to something else, although it need not be GNU strerror_r.

We could always generate "Unknown error %d" ourselves, but then we risk
differing in spelling from glibc (in particular, since glibc translates
"Unknown error %d", but we don't).

On the other hand, since Ulrich _also_ changed glibc from %lu to %d last
week, and since "Unknown error -1" looks nicer than "Unknown error
18446744073709551615", maybe we want to do that anyways - but that
re-raises the question about marking gnulib strings for translation.

> This is simpler than to use two
> different functions from the system. Also "GNU strerror_r always returns
> a thread-safe untruncated string" is an assumption, and if we can write
> code that makes less assumptions, it's better.

So which is better, calling GNU strerror_r to get a translated string,
or blindly falling back to manual "Unknown error %d"?

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]