Geoff Clare wrote:
> Clive D.W. Feather <yyyyy@xxxxxxxxx> wrote, on 27 Feb 2006:
>>David Hopwood said:
>>
>>>You're missing the point. This code:
>>>
>>> fprintf(stderr, "error: %s", strerror(errno));
>>>
>>>can have undefined behaviour.
[...]
>>>The current spec does not require that the returned pointer is either
>>>NULL or a valid NUL-terminated string. It could be a pointer into a
>>>memory-mapped I/O region that causes arbitrary side-effects when read.
>>
>>I am confused. The C99 standard says:
[...]
>>The use of "string" means, from earlier text, that it must be a valid
>>zero-terminated string (and *NOT* NULL). I don't believe that
>>special-effects memory is allowed (if it was, this problem would occur
>>*everywhere* the word "string" is used).
>>
>>If POSIX doesn't have the same "always works" requirement, then it isn't
>>meeting its stated goal of C99-conformance.
>
> This is a known defect in the "RETURN VALUE" section of the POSIX strerror
> description. See XSH ERN 101 which changes:
>
> "Upon successful completion, strerror() shall return a pointer to
> the generated message string."
>
> to:
>
> "Upon completion, whether successful or not, strerror() shall ..."
>
> Since POSIX defers to C99 this requirement is already in effect,
> despite the misleading text in the current standard.
That's an improvement.
However, glibc does not seem to conform to this requirement:
$ cat test2.c
#include <stdio.h>
#include <string.h>
int main(int argc, char **argv) {
printf("%s\n", strerror(-1));
printf("%s\n", strerror(-2));
return 0;
}
$ gcc -ansi -pedantic -Wall test2.c -o test2
$ ./test2
(null)
U%å?ì(☺
This is using a fairly old version of glibc included with Cygwin (it
doesn't seem to have gnu_get_libc_version()). Can anyone confirm with the
latest version of glibc? If so I'll report a bug.
--
David Hopwood <yyyyyyyyyyyyyyyyyyyy@xxxxxxxxxxxxxxxx>
|