It's even simpler. A lot of legacy code out there uses "0" (not NULL or even (void ∗)0, just 0) in place of NULL. So it's very important for backwards compatibility that "test ? (double ∗)x : 0" or "test ? 0 : (int ∗)x" return double ∗ or int ∗, respectively.

I'm not sure why the definition of a null pointer has to be so liberal, but I suspect there's a backwards compatibility constraint in there.

I'm not sure if this covers C++ only, but here's what Stroustrup has to say:

"In C++, the definition of NULL is 0, so there is only an aesthetic difference. I prefer to avoid macros, so I use 0."

That definition is indeed C++-only.

Not sure in which sense it is C++ only. 0 is a null pointer constant in C.

My mistake. I could have sworn that only C++ defined 0 to be equivalent to a null pointer. I guess my confusion stemmed from the fact that the NULL preprocessor macro in C++ is actually defined to be just "0" (or a magical-seeming "__null" in recent versions of g++), whereas in any modern C implementation I've seen, it's "((void *)0)".

Though there are cases in which passing an unadorned "0" as a null pointer can be wrong; there's a null-terminated varargs function example here:

http://c-faq.com/null/null2.html

I don't doubt the C99 committee did a fantastic job maintaining backward compatibility with extant code-bases which use ill- or un-defined semantics of older standards. But I don't think that the success of the committee at doing its job necessarily redeems C99 as a semantically sane language -- indeed, I would argue that the need for design-by-committee is indicative of the hefty baggage of backward-compatibility issues which necessitates such convoluted semantics and boxes the C language into a linguistic dead-end.