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