strerror_r questions
Eric Blake
eblake@redhat.com
Thu Feb 10 07:48:00 GMT 2011
On 02/09/2011 05:29 PM, Eric Blake wrote:
> On 02/09/2011 05:17 PM, Eric Blake wrote:
>> Changes in v2: more documentation, fix the signature, change the default
>> when no feature macros are defined, don't overwrite buf if n is too
>> small, guarantee NUL termination in POSIX variant
>
> Shoot - I missed another POSIX requirement:
>
> "The implementation shall behave as if no function defined in this
> volume of POSIX.1-2008 calls strerror( )."
>
> That is, strerror_r() cannot call strerror() (but we _can_ have a helper
> method that both strerror() and strerror_r() call).
>
> The POSIX requirement means that someone can replace strerror() with
> their own link, but doing so won't affect the behavior of strerror_r().
> Is this something that I should worry about and clean up in a followup
> patch? Or is it too much of a corner case to bother with?
Reading further, POSIX states the reason for that requirement:
"Historically in some implementations, calls to perror( ) would
overwrite the string that the pointer returned by strerror( ) points to."
That is:
#include <stdio.h>
#include <string.h>
#include <errno.h>
int main (void) {
char *err = strerror(1000);
printf("%s", err);
errno = 2000;
peror("hi");
printf("%s", err);
return 0;
}
should result in the first and last lines being the same; but in the
broken case would result in the perror() corrupting the buffer.
Newlib is immune to observing that scenario (unless you provide a
non-standard _user_strerror hook), given that its implementation returns
distinct pointers for all possible errors rather than copying the result
into a common buffer and returning that buffer, and does not do any
formatting of out-of-range values.
But cygwin violates this, since it overrides newlib's strerror() to
format out-of-range numbers into a common reentrant data location, but
uses newlib's perror() which overwrites this location.
--
Eric Blake eblake@redhat.com +1-801-349-2682
Libvirt virtualization library http://libvirt.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 619 bytes
Desc: OpenPGP digital signature
URL: <http://sourceware.org/pipermail/newlib/attachments/20110210/d52b359e/attachment.sig>
More information about the Newlib
mailing list