3 ms·
Generally the committees that design these kinds of things are knowledgeable and careful, so think carefully before accusing them. In the above case, I wonder
by evmar 15y ago
Generally the committees that design these kinds of things are knowledgeable and careful, so think carefully before accusing them.
In the above case, I wonder if it's related to
#define NULL ...something that is a null pointer constant...
and then wanting expressions like
test ? some_double_pointer : NULL
test ? NULL : some_int_pointer
to have the type one would "expect" rather than whatever type NULL has in isolation.
- ootachi 15y agoIt'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.
- jimbobimbo 15y agoI'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."
- kelnos 15y agoThat definition is indeed C++-only.
- kzrdude 15y agoNot sure in which sense it is C++ only. 0 is a null pointer constant in C.
- kelnos 15y agoMy 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 http://c-faq.com/null/null2.html
- colanderman 15y agoI 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.