Eric Blake <ebl...@redhat.com> 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
