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

From: Greywolf <greywolf@starwolf.com>
To: James Chacon <jmc@NetBSD.org>
Cc: YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp>, christos@zoulas.com,
	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 12:49:00 -0700 (PDT)

 [Thus spake James Chacon ("JC: ") 1:20pm...]
 
 JC: The bug you cite doesn't discuss that. It's simply noting that
 JC: printf("%s", NULL) is undefined behavior so basically they're allowed
 JC: to core dump there even on translations to puts().
 
 This is confusing:  Why does printf("%s", NULL) attempt to translate
 into puts() (or am I misreading something here)?
 
 I can see it doing so on literals with no formatting...
 
 If printf() with a NULL dumps core, AND f?puts() with a NULL dumps core,
 well, this is certainly no different than it was when I was programming
 for my CS class.
 
 I also don't see what "(null)" really buys, as more often than not I run
 into dereferencing objects which don't point to NULL, but rather to
 someplace in West Hyperspace.  I guess it's good for catching the id[10].t
 cases where one forgets to assign/test values of pointers (although vars
 in subroutines are not guaranteed to be initialised to zero...hence my
 comment...).
 
 Sorry for distracting.
 
 				--*greywolf;
 --