[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: |
Tue, 24 May 2011 15:54:54 -0600 |
User-agent: |
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc14 Lightning/1.0b3pre Mnenhy/0.8.3 Thunderbird/3.1.10 |
On 05/24/2011 03:30 PM, Simon Josefsson wrote:
> 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.
I think a strerror_r-gnu module might be nice, especially now that I've
posted a patch series that decouples strerror and strerror_r-posix.
Unfortunately, though, we need to think about what happens if both
strerror_r-gnu and strerror_r-posix are imported into the same project
(perhaps because _you_ want to use the GNU signature in your code, but
you also want to use the perror module which implemented using the POSIX
signature)? Which signature wins in each file, and how do you ensure
that all code is compiled with the signature it is expecting?
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.
> 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.
The problem is not necessarily with "Unknown error" (which Solaris
uses), but with implementations that return "", or worse leave buf
uninitialized on error (in fact, even glibc 2.13 is guilty of this,
since it was fixed upstream just last weekend). 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.
--
Eric Blake address@hidden +1-801-349-2682
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
- Re: new files imported without new modules added, (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, 2011/05/24
- Re: strerror vs. threads,
Eric Blake <=
- 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