Title
Address of incomplete type vs operator&()
Status
cd3
Section
8.3.1 [expr.unary.op]
Submitter
Richard Smith

Created on 2012-02-07.00:00:00, last changed 2014-03-03.00:00:00.

Messages

Date: 2012-10-15.00:00:00

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

Date: 2012-02-15.00:00:00

Proposed resolution (February, 2012):

Change 8.3.1 [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.
Date: 2012-02-07.00:00:00

According to 8.3.1 [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.

History
Date User Action Args
2014-03-03 00:00:00adminsetstatus: drwp -> cd3
2013-05-03 00:00:00adminsetstatus: dr -> drwp
2012-11-03 00:00:00adminsetmessages: + msg4133
2012-11-03 00:00:00adminsetstatus: ready -> dr
2012-02-27 00:00:00adminsetmessages: + msg3703
2012-02-07 00:00:00admincreate