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

2023-01-15


556. Conflicting requirements for acceptable aliasing

Section: 7.6.19  [expr.ass]     Status: CD2     Submitter: Mike Miller     Date: 30 January 2006

[Voted into the WP at the March, 2009 meeting.]

There appear to be two different specifications for when aliasing is permitted. One is in 7.2.1 [basic.lval] paragraph 15:

If a program attempts to access the stored value of an object through an lvalue of other than one of the following types the behavior is undefined

There is also a much more restrictive specification in 7.6.19 [expr.ass] paragraph 8:

If the value being stored in an object is accessed from another object that overlaps in any way the storage of the first object, then the overlap shall be exact and the two objects shall have the same type, otherwise the behavior is undefined.

This affects, for example, the definedness of operations on union members: when may a value be stored into one union member and accessed via another.

It should be noted that this conflict existed in C90 and is unchanged in C99 (see, for example, section 6.5 paragraph 7 and section 6.5.16.1 paragraph 3 of ISO/IEC 9899:1999, which directly parallel the sections cited above).

Notes from the October, 2006 meeting:

This issue is based on a misunderstanding of the intent of the wording in 7.6.19 [expr.ass] paragraph 8. Instead of being a general statement about aliasing, it's describing the situation in which the source of the value being assigned is storage that overlaps the storage of the target object. The proposed resolution should make that clearer rather than changing the specification.

Proposed resolution (June, 2008):

Add the following note at the end of 7.6.19 [expr.ass] paragraph 8:

If the value being stored in an object is accessed from another object that overlaps in any way the storage of the first object, then the overlap shall be exact and the two objects shall have the same type, otherwise the behavior is undefined. [Note: This restriction applies to the relationship between the left and right sides of the assignment operation; it is not a statement about how the target of the assignment may be aliased in general. See 7.2.1 [basic.lval]. —end note]