|
|
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.
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.
Take care,
Bill
|
|