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: christos@zoulas.com, 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: Sun, 19 Jun 2005 18:00:28 -0400

 [ Reading the more recent discussion, I come back to this message
 which I think is still the core point. ]
 
 YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp> wrote on Fri, 17 Jun 2005
 at 21:11:49 +0900 in <1119010309.563302.4554.nullmailer@yamt.dyndns.org>:
 
 (quoting Christos):
 > > 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.
 
 I agree with this -- it sounds like any justification for printing
 "(null)" is based on the fact that it is actually used, and there
 is no good reason for fputs() to not have the same checking, other than
 that puts() is rarely called with NULL.
 
 If this gcc cahnge results in fputs() frequently being called with
 NULL, then there is now cause to apply the same checking
 to puts().
 
 > IMO, changing puts is the worst choice because it introduces
 > another non-standard extension.
 > no surprise if a future version of gcc break it. :-)
 
 Anything that gcc rewrites puts() to that core dumps on NULLs is
 probably something that should be producing "(null)" anyhow, and only
 is not right now because we haven't thought about it.
 
 i.e. a future gcc change that breaks this would be break it by
 demonstrating a place where we should have been printing "(null)"
 anyhow.
 
 --jhawk