Subject: Re: port-xen/29887: sysctl kern.consdev coredumps
To: None <firstname.lastname@example.org>
From: YAMAMOTO Takashi <email@example.com>
Date: 06/17/2005 21:11:49
> | 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.
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. :-)