Subject: Re: port-xen/29887: sysctl kern.consdev coredumps
To: None <gnats-bugs@NetBSD.org, netbsd-bugs@NetBSD.org,>
From: Alan Barrett <apb@cequrux.com>
List: netbsd-bugs
Date: 06/20/2005 17:28:25
On Mon, 20 Jun 2005, James Chacon wrote:
> 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"
When function X is defined by some standard, and the programmer told
the compiler to use that standard, I think it's unreasonable for the
programmer to expect anything like what we conventionally refer to as
a "function call" to occur. Instead, the programmer should expect the
standard-defined effects to occur, and not care whether those effects
happen through compiler magic or through an actual "function call".
> Using your logic above, no implementation can ever extend any standard
> defined function.
No, by my logic, you are free to extend a standard-defined function,
provided you don't attempt to lie to the compiler. Telling the compiler
"This code expects to run in an environment like that defined in
standard A", when in reality the code expects to run in an extension of
that environment, is lying to the compiler. In other words, don't pass
"-std=c99" (or similar) to the compiler if you don't really mean it.
> A compiler by your logic could completely supply libc internally and
> not call your system supplied one with extentions you may be depending
> on.
Yes, a compiler could do that, to the extent permitted by the
standards that you tell the compiler to use. Again, don't tell the
compiler "-std=c99" if you are relying on printf("%s",NULL) to print
"(null)", or if you are relying on any other non-standard extensions to
standard-defined functions.
(Actually, the compiler and the system-supplied libraries are
intended to be tightly integrated, and to cooperate to provide the
execution environment specified by the standards.)
--apb (Alan Barrett)