> > if you follow gcc (ie. honor compiler's right to do
> > this kind of optimization), you can't use non-standard extensions anyway.
> > 
> > if you don't follow gcc (ie. disable the optimization),
> > you don't need to extend the extension to puts.
> > 
> > in either way, i don't see any good reason to propagate
> > the extention to puts.
> 
> You've defined everything in a very black & white manner, and in such a 
> way that both scenarios support your opinion. That's not really a good 
> starting point for an exchange of ideas.

i did so because they are only sane scenarios i can think of.

> 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.
besides, gcc is also free to optimize puts not to use our puts.

> The reality is we will probably have to live with gcc making assumptions 
> for us. 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.

you can't assume how gcc optimizes printf.
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.

YAMAMOTO Takashi