[ Reading the more recent discussion, I come back to this message
which I think is still the core point. ]

YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp> wrote on Fri, 17 Jun 2005
at 21:11:49 +0900 in <1119010309.563302.4554.nullmailer@yamt.dyndns.org>:

(quoting Christos):
> > 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.

I agree with this -- it sounds like any justification for printing
"(null)" is based on the fact that it is actually used, and there
is no good reason for fputs() to not have the same checking, other than
that puts() is rarely called with NULL.

If this gcc cahnge results in fputs() frequently being called with
NULL, then there is now cause to apply the same checking
to puts().

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

Anything that gcc rewrites puts() to that core dumps on NULLs is
probably something that should be producing "(null)" anyhow, and only
is not right now because we haven't thought about it.

i.e. a future gcc change that breaks this would be break it by
demonstrating a place where we should have been printing "(null)"
anyhow.

--jhawk