Re: Bad gcc -O optimization cause core dump. What to do?

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