This is an unofficial snapshot of the ISO/IEC JTC1 SC22 WG21 Core Issues List revision 108h. See http://www.open-std.org/jtc1/sc22/wg21/ for the official list.

2022-07-01


1458. Address of incomplete type vs operator&()

Section: 7.6.2.2  [expr.unary.op]     Status: CD3     Submitter: Richard Smith     Date: 2012-02-07

[Moved to DR at the October, 2012 meeting.]

According to 7.6.2.2 [expr.unary.op] paragraph 5,

The address of an object of incomplete type can be taken, but if the complete type of that object is a class type that declares operator&() as a member function, then the behavior is undefined (and no diagnostic is required).

This should actually be “ill-formed, no diagnostic required” instead of undefined behavior, since the problem could be detected by whole-program analysis. Also, it's not clear what this means for constant expressions.

Proposed resolution (February, 2012):

Change 7.6.2.2 [expr.unary.op] paragraph 5 as follows:

The address of an object of incomplete type can be taken, but if the complete type of that object is a class type that declares operator&() as a member function, then the behavior is undefined (and no diagnostic is required). If & is applied to an lvalue of incomplete class type and the complete type declares operator&(), it is unspecified whether the operator has the built-in meaning or the operator function is called. The operand of & shall not be a bit-field.