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

From: James Chacon <jmc@NetBSD.org>
To: Jason Thorpe <thorpej@shagadelic.org>
Cc: Greywolf <greywolf@starwolf.com>, John Hawkinson <jhawk@MIT.EDU>,
	YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp>, gnats-bugs@NetBSD.org,
	port-xen-maintainer@NetBSD.org, netbsd-bugs@NetBSD.org,
	tech-userlevel@NetBSD.org
Subject: Re: port-xen/29887: sysctl kern.consdev coredumps
Date: Tue, 21 Jun 2005 16:28:22 -0500

 On Tue, Jun 21, 2005 at 02:06:44PM -0700, Jason Thorpe wrote:
 > 
 > On Jun 21, 2005, at 1:53 PM, James Chacon wrote:
 > 
 > >i.e. we should now have printfEx for anything printf related the  
 > >standard
 > >didn't cover...
 > 
 > In the NetBSD case, it could even be a weak symbol that points to  
 > printf!  By doing this, you are telling the implementation that you  
 > are explicitly relying on extensions (how is the implementation to  
 > know otherwise that you expect NULL to really mean "(null)"?).
 
 To (me at least) the "implementation" is the compiler + the libraries.
 
 Gcc is assuming it's the complete implementation here, it knows best and how
 everything was setup/provided. This is not a valid assumption. The standard
 says how a certain class of operations *must* perform but doesn't disallow
 for extensions either. Since the compiler in this cannot know what extensions
 may/may not exist in the full implementation (since it's not also providing
 the standard library) making assumptions about what it can do to the
 implementation is an error (IMO).
 
 If gcc provided these functions itself and knew absolutely there were no
 side effects/differences between printf->puts substitutions then I'd have
 no argument here. Certainly this is the case with libgcc provided calls. 
 
 The fact is, because gcc only provides 1 piece of the overall picture it 
 should not just assume the rest of the picture unless I've told it to (say 
 with std=c99, etc).
 
 James