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

From: John Hawkinson <jhawk@MIT.EDU>
To: YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp>
Cc: 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 09:13:10 -0400

 YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp> wrote on Tue, 21 Jun 2005
 at 21:22:59 +0900 in <1119356579.718336.1241.nullmailer@yamt.dyndns.org>:
 
 > > Exactly what puts() does is up to us in the areas of "standards undefined" 
 > > behavior, is it not? So we are free to add "(null)" support as I 
 > > understand it. I really don't see why we shouldn't. What do you think will 
 > > be broken or what will we lose?
 > 
 > yes, we are free to add it to our puts.
 > however, i think it's a bad idea as i wrote in my another mail.
 
 "because it introduces another non-standard extension"? That does not
 seem like a very compelling reason.
 
 > besides, gcc is also free to optimize puts not to use our puts.
 
 True. And then we are free to reconsider what to do about this problem
 when the time comes.  But it seems a relatively unlikely case that we
 would be able to easily deal with, should the time come. So why worry?
 
 > although it might happen to "fix" the problem at this point,
 > introducing another extention which is not recognized by gcc
 > just makes the situation worse.
 
 I just don't see it making the situation worse. There are lots of
 things our libc does that may not be specified explicitly in POSIX.
 That's not a problem, and we don't worry about potential
 future gcc optimizations each time we add or change one.
 
 
 Changing puts() allows us to keep the behavior many find desirable at
 a very low cost. We don't have to worry about getting our gcc out of
 sync with the mainline, which is quite a big deal. We don't have to
 worry about fighting a difficult battle with the gcc maintainers to
 revert the change (it hardly seems like such a battle could be won
 within the NetBSD community, so expecting to win it with the gcc
 maintainers seems pretty tough). 
 
 --jhawk