strerror_r questions
Eric Blake
eblake@redhat.com
Thu Feb 10 16:25:00 GMT 2011
On 02/10/2011 02:18 AM, Corinna Vinschen wrote:
>> The "Unknown error XXX" message is a cygwin artifact, not a newlib
>> artifact. That is, cygwin should be using it's own strerror_r, since it
>> provides its own strerror() with different behavior than newlib's.
>
> The "Unknown error XXX" is not a Cygwin artifact, it's standard glibc
> behaviour, see `man strerror_r' on Linux:
It's actually recommended (but not required) POSIX behavior. It's just
that it gets expensive to implement on embedded systems.
>> The glibc docs state merely that the return value is
>> NUL-terminated, not that buf is also NUL-terminated (which, for n==0, is
>> impossible).
>
> That's not how I understand the sentence
>
> If the function stores a string in buf, then at most buflen bytes are
> stored (the string may be truncated if buflen is too small) and
> the string always includes a terminating null byte.
Glibc documentation is ambiguous - first it states that if n is too
small, then buf is not modified nor returned; then it states that if n
is too small, buf gets a truncated string. An actual test program
proves the point:
$ cat foo.c
#define _GNU_SOURCE 1
#include <stdio.h>
#include <string.h>
#include <errno.h>
int main (void) {
char buf[80] = "Hello world";
char *p = strerror_r (1, buf, 4);
printf ("buf=%s\np=%s\n", buf, p);
return 0;
}
$ ./foo
buf=Hello world
p=Operation not permitted
I'll be submitting a bug report to the Linux man-pages project.
--
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/9044c641/attachment.sig>
More information about the Newlib
mailing list