On Sun, Jun 19, 2005 at 02:49:57AM -0400, Nathan J. Williams wrote:
> Greywolf <greywolf@xxxxxxxxxxxx> 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.
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.