On Mon, Jun 20, 2005 at 01:56:02PM -0700, Bill Studenmund wrote:
> On Sun, Jun 19, 2005 at 02:49:57AM -0400, Nathan J. Williams wrote:
> > Greywolf <greywolf@starwolf.com> writes:
> > 
> > > Could you please enlighten me, at least, as to where the standard defines
> > > that a library call can be overridden on a whim by the compiler, much less
> > > without explicit request by the programmer?
> > 
> > A library call is defined to have a particular effect.
> 
> I think this statement hits on a big part of the problem. Ever since March 
> 21, 1993, NetBSD's printf() has done the (null) substitution; it was part 
> of the 4.4BSD libc. This behavior also never made it into the man pages.
> 
> The fact that our printf(3) did the NULL -> "(null)" transformation for
> ten years certainly got noticed and became an expected behavior. In
> effect, it became defined (for *BSD) in common experience. I certainly
> have come to expect it. ;-) I also think that it makes our code more
> readable and ever so slightly smaller as we don't have to test for NULL
> and then keep multiple copies of "(null)" around.
> 
> > Any code the compiler generates with this effect is valid.
> 
> I agree.
> 
> The problem is, as in this case, when the library call is defined (either
> expicitly or through past behavior) by the OS/library developer
> differently from what the gcc developers thought it was defined to do. 
> Thus the change the compiler makes generates a different effect.
> 
> If we aren't running at some conformance level (-ansi, etc.), then who 
> fundamentally gets to decide? The compiler or the OS vendor?
> 
> I think the best thing for NetBSD to do now is to add the NULL -> "(null)" 
> transform to fputs() and pull the change into 3.X and 2.1. Then the 
> assumption gcc is making, that printf("%s\n", NULL) is the same as 
> puts(NULL), will be true.
> 
> A longer term fix would be to somehow express to gcc what assumptions are 
> appropriate when not in a set-standard (-ansi, C99, etc.) mode. But I 
> realize that may be a lot of work for little gain.

This is why people have asked/said this specific "extention" should be
explicitly enabled with a -f flag. I'm not apposed to what it's doing, just
that since it's not as simple as an optimized memcpy, it's actually calling
another function this shouldn't be something the compiler just sneaks in on
you.

James