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
[Voted into the WP at the March, 2009 meeting.]
There appear to be two different specifications for when aliasingis permitted. One is in 7.2.1 [basic.lval] paragraph 15:
If a program attempts to access the stored value of an object throughan lvalue of other than one of the following types the behavior isundefined
the dynamic type of the object,
a cv-qualified version of the dynamic type of theobject,
a type similar (as defined in 7.3.6 [conv.qual]) tothe dynamic type of the object,
a type that is the signed or unsigned type corresponding to thedynamic type of the object,
a type that is the signed or unsigned type corresponding to acv-qualified version of the dynamic type of the object,
an aggregate or union type that includes one of theaforementioned types among its members (including, recursively, amember of a subaggregate or contained union),
a type that is a (possibly cv-qualified) base class type of thedynamic type of the object,
achar orunsigned char type.
There is also a much more restrictive specification in7.6.19 [expr.assign] paragraph 8:
If the value being stored in an object is accessed from another objectthat overlaps in any way the storage of the first object, then theoverlap shall be exact and the two objects shall have the same type,otherwise the behavior is undefined.
This affects, for example, the definedness of operationson union members: when may a value be stored into one unionmember and accessed via another.
It should be noted that this conflict existed in C90 and isunchanged in C99 (see, for example, section 6.5 paragraph 7 andsection 6.5.16.1 paragraph 3 of ISO/IEC 9899:1999, which directlyparallel the sections cited above).
Notes from the October, 2006 meeting:
This issue is based on a misunderstanding of the intent of thewording in 7.6.19 [expr.assign] paragraph 8. Instead ofbeing a general statement about aliasing, it's describing thesituation in which the source of the value being assigned is storagethat overlaps the storage of the target object. The proposedresolution should make that clearer rather than changing thespecification.
Proposed resolution (June, 2008):
Add the following note at the end of 7.6.19 [expr.assign] paragraph 8:
If the value being stored in an object is accessed from another objectthat overlaps in any way the storage of the first object, then theoverlap shall be exact and the two objects shall have the same type,otherwise the behavior is undefined.[Note: This restrictionapplies to the relationship between the left and right sides of theassignment operation; it is not a statement about how the target ofthe assignment may be aliased in general. See 7.2.1 [basic.lval]. —end note]