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

From: Greywolf <greywolf@starwolf.com>
To: John Hawkinson <jhawk@MIT.EDU>
Cc: 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 10:14:29 +0000

 John Hawkinson wrote:
 
 >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
 >  
 >
 It makes the situation worse because, as has been pointed out, what if 
 our puts()
 does something we desire, and then gcc goes and inlines its own puts() which
 routes around anything we might do?
 
 Apply this scenario to any other function call outside 
 printf()/f*puts().  Would
 it be considered acceptable there?
 
 Granted, accessing outside the process space is something from which the
 programmer should be protecting his programs, so that's not the issue, here.
 The issue here is that the compiler seems to be given free license to 
 replace
 an implemented function with known behaviour with its own inlined version.
 
 In short, if the compiler is part of the implementation, as has been stated,
 that gives the compiler license to completely supplant anything we do with
 anything it wishes.  And if that oversteps the bounds of "undefined 
 behaviour",
 This Is Not Cool, Beavis.
 
 With regard to "(null)" vs. "Bus error (Core dumped).", that doesn't matter
 to me, other than being a potential nicety.  What matters to me is the
 compiler is pretending it knows what I want, even though I am not asking
 for it.  It's like walking into a shop and asking for a ham and jack 
 sandwich
 and getting mortadella and mozzarella.  Sure, it might be "better", but
 it's not what I expected, much less what I asked for.
 
 
 -- 
 				--*greywolf;