Collin Funk wrote:
> Using the test program:
>
> $ cat main.c
> #include <stdio.h>
> int
> main (void)
> {
> fprintf (stdout, "%s\n", NULL);
> return 0;
> }
>
> On GNU/Linux:
>
> $ gcc main.c
> $ ./a.out
> (null)
Using the modified test program:
#include <stdio.h>
int
main (void)
{
fprintf (stdout, "%s", NULL);
fprintf (stdout, "\n");
return 0;
}
On GNU/Linux:
$ gcc foo.c
$ ./a.out
Segmentation fault (core dumped)
$ nm a.out | grep ' U '
U fputc@GLIBC_2.2.5
U fputs@GLIBC_2.2.5
U __libc_start_main@GLIBC_2.34
So, due to GCC optimizations, using NULL as argument for %s is unreliable
even on systems with glibc.
> However, it appears the m4/*printf.m4 files do not check for the
> behavior so we cannot depend on it.
>
> Bruno, do you recall if this was intentional? Or do you think it should
> be added?
It is intentional, because that glibc feature is not specified by POSIX.
It should not be added, because you can't rely on it anyway, due to GCC
optimizations.
By the way, Ubuntu's patched gcc warns about it:
$ gcc foo.c
foo.c: In function ‘main’:
foo.c:5:22: warning: format ‘%s’ expects argument of type ‘char *’, but
argument 3 has type ‘void *’ [-Wformat=]
5 | fprintf (stdout, "%s\n", NULL);
| ~^
| |
| char *
| %p
foo.c:5:21: warning: ‘%s’ directive argument is null [-Wformat-overflow=]
5 | fprintf (stdout, "%s\n", NULL);
| ^~
Bruno
