> | if no one objects, i will:
> | 
> | 	- add some note to printf(3) to discourage the use of "(null)".
> | 	- remove code to produce the "(null)" from wprintf and friends.
> 
> This has been historical practice since the mid 80's. People expect *printf(3)
> to print (null) when you pass it a null string. It is a lot better to print
> (null) than to core-dump... Trust me, I remember how it was back then.
> 
> | 	- and disable the optimization in in-tree gcc.
> 
> This will just muddle the waters even further. Imagine when a poor
> sod compiles a new version of gcc and some code randomly core-dumps
> with the new gcc where it works with the in-tree gcc. I.e. "Our"
> gcc will be different than the rest of the world. I may disagree
> with the optimization, but this is the de-facto gcc behavior.

because gcc's "optimization" conflicts with printf's histrical practice,
we need to give up at least either of them.

> In short, I oppose all three changes. I still think that changing
> puts and fputs to behave like printf() is a saner choice. I would
> prefer if core voted for it, and since I am in core, I will abstain
> from this one.
> 
> christos

adding a hack to libc for the broken compiler is saner?
i don't think so.

the fundamental problem is that gcc ignores the well-known but non-standard
behaviour of printf.  fixing gcc is the right fix.

IMO, changing puts is the worst choice because it introduces
another non-standard extension.
no surprise if a future version of gcc break it. :-)

YAMAMOTO Takashi