Subject: Re: port-xen/29887: sysctl kern.consdev coredumps
To: Alan Barrett <firstname.lastname@example.org>
From: James Chacon <jmc@NetBSD.org>
Date: 06/20/2005 08:36:06
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