Date: 2015-05-15.00:00:00

[Moved to DR at the May, 2015 meeting.]

Date: 2014-11-15.00:00:00

Proposed resolution (November, 2014):

Change 7.6.10 [expr.eq] paragraph 2, converting the existing running text into bullets, as follows:

If at least one of the operands is a pointer, pointer conversions (7.3.12 [conv.ptr]) and qualification conversions (7.3.6 [conv.qual]) are performed on both operands to bring them to their composite pointer type (Clause 7 [expr]). Comparing pointers is defined as follows: Two pointers compare equal

• If one pointer represents the address of a complete object, and another pointer represents the address one past the last element of a different complete object [Footnote: An object that is not an array element is considered to belong to a single-element array for this purpose; see 7.6.2.2 [expr.unary.op]. —end footnote], the result of the comparison is unspecified.

• Otherwise, if they the pointers are both null, both point to the same function, or both represent the same address (6.9.5 [basic.compound]), they compare equal.

• otherwise they Otherwise, the pointers compare unequal.

Date: 2013-04-15.00:00:00

Pointer equality is defined by reference to the addresses of the objects designated by the pointer values, reflecting the implementation technique of most/all compilers. However, this definition is intrinsically a runtime property, and such a description is inappropriate with respect to constexpr expressions, which must deal with pointer comparisons without necessarily knowing the runtime layout of the objects involved. A better definition usable at compile time is needed.