This is an unofficial snapshot of the ISO/IEC JTC1 SC22 WG21 Core Issues List revision 119a. See http://www.open-std.org/jtc1/sc22/wg21/ for the official list.
2025-12-20
[Moved to DR status at the April, 2013 meeting.]
Consider the following example:
void f(int*); void f(...); template <int N> void g() { f(N); } int main() { g<0>(); g<1>(); }The call tof ing is not type-dependent, so theoverload resolution must be done at definition time rather than atinstantiation time. As a result, both of the calls togwill result in calls tof(...), i.e.,N will notbe a null pointer constant, even if the value ofN is 0.
It would be most consistent to adopt a rule that a value-dependentexpression can never be a null pointer constant, even in cases like
template <int N> void g() { int* p = N; }This would always be ill-formed, even whenN is 0.
John Spicer: It's clear that this treatment is required foroverload resolution, but it seems too expansive given that there areother cases in which the value of a template parameter can affectthe validity of the program, and an implementation is forbidden toissue a diagnostic on a template definition unless there are nopossible valid specializations.
Notes from the July, 2009 meeting:
There was a strong consensus among the CWG that only the literal0 should be considered a null pointer constant, not anyarbitrary zero-valued constant expression as is currently specified.
Proposed resolution (October, 2012):
Change 7.3.12 [conv.ptr] paragraph 1 as follows:
Anull pointer constant is anintegral constant expression(7.7 [expr.const]) prvalue of integer type that evaluatestointeger literal (5.13.2 [lex.icon]) withvalue zero or a prvalue of typestd::nullptr_t. A nullpointer constant can be converted...
Change 7.7 [expr.const] paragraph 3 as follows:
...[Note: Such expressions may be used as array bounds(9.3.4.5 [dcl.array], 7.6.2.8 [expr.new]), as bit-fieldlengths (11.4.10 [class.bit]), as enumerator initializers if theunderlying type is not fixed (9.8.1 [dcl.enum]),as nullpointer constants (7.3.12 [conv.ptr]),and as alignments(9.13.2 [dcl.align]). —end note]...
Change 9.5 [dcl.init] paragraph 5 as follows:
Tozero-initialize an object or reference of typeTmeans:
ifT is a scalar type (6.9 [basic.types]),the object is
set to the value0 (zero), taken as an integralconstant expression, convertedinitialized to the valueobtained by converting integer literal0 (zero) toT; [Footnote: As specified in 7.3.12 [conv.ptr], converting anintegral constant expressioninteger literal whose value is 0 to a pointer type resultsin a null pointer value. —end footnote]...
Change 13.4.3 [temp.arg.nontype] paragraph 5 as follows:
...
for a non-typetemplate-parameter of type pointer toobject, qualification conversions (7.3.6 [conv.qual]) and thearray-to-pointer conversion (7.3.3 [conv.array]) are applied; ifthetemplate-argument is of typestd::nullptr_t, thenull pointer conversion (7.3.12 [conv.ptr]) is applied.[Note: In particular, neither the null pointer conversion for azero-valuedintegral constant expressionintegerliteral (7.3.12 [conv.ptr]) nor the derived-to-baseconversion (7.3.12 [conv.ptr]) are applied. Although 0is...
...
Change 14.4 [except.handle] paragraph 3 as follows:
...[Note: Athrow-expression whose operand is anintegral constant expression of integer type that evaluatestointeger literal with value zero does not match ahandler of pointer or pointer to member type. —endnote]. [Example: ...
Add a new section to C.6 [diff.cpp03] as follows:
C.2.x Clause 4: standardconversions [diff.cpp03.conv] 7.3.12 [conv.ptr]
Change: Only literals are integer null pointer constants
Rationale: Removing surprising interactions with templatesand constant expressions
Effect on original feature: Valid C++ 2003 code may fail tocompile or produce different results in this International Standard,as the following example illustrates:void f(void *); // #1 void f(...); // #2 template<int N> void g() { f(0*N); // calls #2; used to call #1 }
Additional note (January, 2013):
Concerns were raised at the Portland (October, 2012) meeting that the valuefalsehas been used in existing code as a null pointer constant, andsuch code would be broken by this change. This issue has been returnedto "review" status to allow discussion of whether to accommodate suchcode or not.