> 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?

The only think I can think of is that it will encourage the gcc
maintainers to do the same thing again in the future.

However, since the consensus, insofar as there is one, seems to be that
this change is a Good Thing, that's probably something NetBSD wants to
encourage.  Go for it.

> The reality is we will probably have to live with gcc making
> assumptions for us.

Not if they're curbed sharply now, when this sort of rewriting is still
in its infancy.

> And to be honest, if we change puts(), then the assumption gcc makes
> (that printf("%s\n", x) yields the same effect as puts(x) for all x)
> is once again true.

No...not the same effect.  Just somewhat closer to the same.

It does mean you can't set a braekpoint at printf and expect it to
catch all your calls to printf.  But I suppose that carries no more
weight than "it's how it's always worked".

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B