The following reply was made to PR port-xen/29887; it has been noted by GNATS.

From: James Chacon <jmc@NetBSD.org>
To: Alan Barrett <apb@cequrux.com>
Cc: gnats-bugs@NetBSD.org, netbsd-bugs@NetBSD.org,
	tech-userlevel@NetBSD.org
Subject: Re: port-xen/29887: sysctl kern.consdev coredumps
Date: Mon, 20 Jun 2005 08:36:06 -0500

 On Mon, Jun 20, 2005 at 12:03:49PM +0200, Alan Barrett wrote:
 > On Fri, 17 Jun 2005, Christos Zoulas wrote:
 > > I don't think so either, but when you ask the compiler to call printf(),
 > > and it calls puts() because it `knows' it is better, what else are you
 > > left with?
 > 
 > In my opinion, the compiler should decide whether or not it is
 > allowed to convert printf("%s",foo) to puts(foo) [and similarly with
 > fprintf/fputs] depending on what standards you told the compiler that
 > the code was intended to conform to.
 > 
 > For example, if you tell the compiler that the code conforms to the
 > hosted environment defined in ANSI/ISO 9899:1989, then the compiler
 > can know that printf("%s",NULL) invokes undefined behaviour, and the
 > programmer shouldn't care whether the undefined behaviour results in a
 > core dump or in the string "(null)" being printed.
 
 Ummm....There's also an expectation from a programmer that when I say
 "call function X" I actually meant "call that function" not "simulate calling
 that function only to the degree the compiler considers acceptable"
 
 Using your logic above, no implementation can ever extend any standard
 defined function. A compiler by your logic could completely supply libc
 internally and not call your system supplied one with extentions you may be
 depending on.
 
 James