Bad gcc -O optimization cause core dump. What to do?
Eygene Ryabinkin
rea-fbsd at codelabs.ru
Tue Mar 13 13:34:06 UTC 2007
Slightly off-topic, sorry.
> > > Any ideas? Is it right or needs to be fixed?
> >
> > It is definitely not right, since it produces the bad code.
> > And there are no compilation-time checks that can say for
> > sure will the argument for the "%s" be NULL:
>
> This is simply a programming error. Just because the function is called
> printf doesn't make it right. It's nice that the libc's printf does all
> these neat tricks, but it's also expensive (See the link I posted
> earlier). According to the printf(3) manpage:
>
> s The char * argument is expected to be a pointer to an array of
> character type (pointer to a string). Characters from the array
> are written up to (but not including) a terminating NUL charac-
> ter; if a precision is specified, no more than the number speci-
> fied are written. If a precision is given, no null character
> need be present; if the precision is not specified, or is greater
> than the size of the array, the array must contain a terminating
> NUL character.
>
> And I fail to see how "NULL" is a valid pointer to an array of character
> type. This is C after all.
In linux there were times (in 2.6 kernel) when mmap was able to
return NULL as the handle to a perfectly valid memory area. So
NULL is sometimes a good pointer. But it is not our case, so
this was off-topic, just for the curiosity.
I just wanted to point out that the familiar behaviour of printf()
can be restored with the -fno-builtin-printf flag.
--
Eygene
More information about the freebsd-current
mailing list