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

From: YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp>
To: christos@zoulas.com
Cc: gnats-bugs@netbsd.org, port-xen-maintainer@netbsd.org,
	gnats-admin@netbsd.org, netbsd-bugs@netbsd.org,
	tech-userlevel@netbsd.org
Subject: Re: port-xen/29887: sysctl kern.consdev coredumps
Date: Fri, 17 Jun 2005 21:11:49 +0900

 > | if no one objects, i will:
 > | 
 > | 	- add some note to printf(3) to discourage the use of "(null)".
 > | 	- remove code to produce the "(null)" from wprintf and friends.
 > 
 > This has been historical practice since the mid 80's. People expect *printf(3)
 > to print (null) when you pass it a null string. It is a lot better to print
 > (null) than to core-dump... Trust me, I remember how it was back then.
 > 
 > | 	- and disable the optimization in in-tree gcc.
 > 
 > This will just muddle the waters even further. Imagine when a poor
 > sod compiles a new version of gcc and some code randomly core-dumps
 > with the new gcc where it works with the in-tree gcc. I.e. "Our"
 > gcc will be different than the rest of the world. I may disagree
 > with the optimization, but this is the de-facto gcc behavior.
 
 because gcc's "optimization" conflicts with printf's histrical practice,
 we need to give up at least either of them.
 
 > In short, I oppose all three changes. I still think that changing
 > puts and fputs to behave like printf() is a saner choice. I would
 > prefer if core voted for it, and since I am in core, I will abstain
 > from this one.
 > 
 > christos
 
 adding a hack to libc for the broken compiler is saner?
 i don't think so.
 
 the fundamental problem is that gcc ignores the well-known but non-standard
 behaviour of printf.  fixing gcc is the right fix.
 
 IMO, changing puts is the worst choice because it introduces
 another non-standard extension.
 no surprise if a future version of gcc break it. :-)
 
 YAMAMOTO Takashi