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 ebl...@redhat.com +1-801-349-2682
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
