------- Comment #2 from roger at eyesopen dot com 2006-03-28 21:46 ------- I believe that this may not be a g++ bug. The wording of the standard is: [conv.ptr] An null pointer constant is an *integral* constant expression (_expr.const_) rvalue of integer type that evaluates to zero. Ignoring the term "rvalue" which was the cause of the misinterpretation of PR13867, the important aspect is the explicit use of "integral".
Both [expr.const] and [basic.fundamental] distinguish between integral and enumeration constants. Hence, given the definition "enum { NULL = 0 };", I believe that "NULL" is an "enumeral constant expression", and that "(int)NULL" is "integral constant expression". Note that enumerators may appear in "integral constant expressions", but are not themselves "integral constant expressions". See footnote 20) in section [basic.fundamental] that reiterates: 20) Therefore, enumerations (_dcl.enum_) are not integral; however, enumerations can be promoted to int, unsigned int, long, or unsigned long, as specified in _conv.prom_. Note that a standard conversion can contain at most one conversion from the set "integral promotions" [conv.prom] and "pointer conversions" [conv.ptr]. i.e. you can't get from enumerator to a pointer in a single "standard conversion sequence", by my reading of the wording. Hence in your testcase foo(NULL) is probably invalid, but foo((int)NULL) should be fine. Notice if that foo is overloaded, i.e. foo(int) and foo(int*), there is no ambiguity with using foo(NULL). Although this could perhaps be supported as a GNU extension in cp/call.c:standard_conversion, if there are other compilers that support this, the fact that there's a simple fix to make the source code standard conforming, means that such a patch would unlikely be accepted. Of course, this may be poor wording in the standard. I notice that Stroustrup originally used the wording "A constant expression that evaluates to 0 ...", and again states that "a constant expression evaluates to an integral or enumeration constant.". So this looks like something standardization tightened up. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14644