Subject: Re: port-xen/29887: sysctl kern.consdev coredumps
To: Nathan J. Williams <>
From: Bill Studenmund <>
List: tech-userlevel
Date: 06/20/2005 13:56:02
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sun, Jun 19, 2005 at 02:49:57AM -0400, Nathan J. Williams wrote:
> Greywolf <> writes:
> > Could you please enlighten me, at least, as to where the standard defin=
> > that a library call can be overridden on a whim by the compiler, much l=
> > 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.=20
Thus the change the compiler makes generates a different effect.

If we aren't running at some conformance level (-ansi, etc.), then who=20
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=20
assumption gcc is making, that printf("%s\n", NULL) is the same as=20
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=20
realize that may be a lot of work for little gain.

Take care,


Content-Type: application/pgp-signature
Content-Disposition: inline

Version: GnuPG v1.2.3 (NetBSD)