[Jason Thorpe <thorpej@shagadelic.org>]
>> If fixing this bug would be seen as [...]
> IT IS NOT A BUG.  GCC is perfectly within its rights to do what it is
> doing.

The one does not imply the other.

> Maybe people should stop passing NULL pointers to printf() in the
> first place?

What I am calling a bug is not the change in the semantics of nil
pointers passed to printf, but rather the compiler rewriting a call to
printf into a call to {,f}puts.

I call it a bug not in the sense of "it's forbidden to do that" but
rather in the sense of "the compiler should be *useful*, not do
everything it is possibly allowed to by the spec to surprise people".

There is a place for compilers that deliberately break all the things
the spec allows them to.  But routine use without special options
isn't, in my opinion, it.

[James Chacon <jmc@NetBSD.org>]
> Where is it stated in the standard the compiler is allowed to
> "optimize" calls to function A to map instead to function B entirely
> under the covers for me?

The "as if" rule.  When compiling in a hosted environment, if <stdio.h>
has been #included, printf becomes, more or less, a reserved word, with
certain semantics (specified in the standard).  The compiler is
confusing the semantics of the pseudo-reserved-words printf and fputs
with the semantics of the library functions printf and fputs, deciding
that because the abstract semantics of a particular call to printf are
equivalent to the abstract semantics of a particular call to fputs,
it's acceptable to implement those abstract semantics with a call to
the real fputs function rather than the real printf function.

[Martin Husemann <martin@duskware.de>]
>> Does it violate the principle of least surprise that the compiler is
>> deciding to call entirely different functions for me because it
>> decided that was "optimal" when all I did was specify -O2 or -O3?
> Not more than memcpy() being inlined and getting alignment
> restrictions that the "real" memcpy does not have.

I'm inclined to agree with you.  memcpy should not be inlined unless
some suitable option - probably the same one that enables converting
special cases of printf to fputs - is given.

Acquiring alignment restrictions, that is *definitely* a bug, to my
mind.  memcpy() as specified does not have alignment restrictions, so
an inlining of it that does is an invalid transformation - unless the
compiler can prove those restrictions are always satisfied for that
particular call.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B