[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: strerror vs. threads
From: |
Simon Josefsson |
Subject: |
Re: strerror vs. threads |
Date: |
Wed, 25 May 2011 10:59:25 +0200 |
User-agent: |
Gnus/5.110018 (No Gnus v0.18) Emacs/23.2 (gnu/linux) |
Eric Blake <address@hidden> writes:
> 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.
Yes. What we'd really like is a dependency scheme that can express
something like "strerror_r-gnu | strerror_r-posix"...
>> 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).
Ah. That's bad, and should definitely be replaced..
> 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.
/Simon
- Re: new files imported without new modules added, (continued)
- 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, 2011/05/24
- Re: strerror vs. threads,
Simon Josefsson <=
- 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