Proposed resolution for DR236

I believe the committee's intentions for the issues raised in DR236 can be realized simply by applying the "visible union" clause to the "aliasing" rule instead of the "common initial sequence" rule, as follows:

§6.5.2.3¶5:

One special guarantee is made in order to simplify the use of unions: if a union contains several structures that share a common initial sequence (see below), and if the union object currently contains one of these structures, it is permitted to inspect the common initial part of any of them anywhere that a declaration of the complete type of the union is visible. Two structures share a common initial sequence if corresponding members have compatible types (and, for bit-fields, the same widths) for a sequence of one or more initial members.

§6.5¶7:

An object shall have its stored value accessed only by an lvalue expression that has one of the following types:

• a type compatible with the effective type of the object,
• a qualified version of a type compatible with the effective type of the object,
• a type that is the signed or unsigned type corresponding to the effective type of the object,
• a type that is the signed or unsigned type corresponding to a qualified version of the effective type of the object,
• the type of any member of any complete union type with a member having one of the aforementioned types,
• an aggregate or union type that includes one of the aforementioned types among its members (including, recursively, a member of a subaggregate or contained union), or
• a character type.

In Curaçao some people (possibly including myself) believed that it would also be necessary to apply the effective type rule to unions, but from a practical perspective, I don't see the need. Whether the aliased memory is an object declared as a union (as in example 2), or a dynamically-allocated object (example 1) doesn't matter in terms of the viability of the optimization. In both cases, all that really matters is whether an appropriate union is visible at the point of access.

Having "opened up" §6.5¶7, I thought I would also present another wording change, related to point three of DR257.

The minutes from Curaçao basically indicated that the committee thought that a change was warranted, but hinted that the committee didn't want to undertake it now. On the off chance that the reason for delay might have been based at least partly on drafting difficulty, here is a concrete proposal for the committee's consideration.

It is also possible that the committee felt that this issue does not strictly represent a defect in the standard, but is more along the lines of a missing feature. But my feeling is that the statement in several footnotes that "the same representation and alignment requirements are meant to imply interchangeability as ... members of unions" is not today implied by the text of the standard, so this does represent a defect.

§6.5¶7:

An object shall have its stored value accessed only by an lvalue expression that has one of the following types:

• a type compatible with the effective type of the object,
• a qualified version of a type compatible with the effective type of the object,
• a type that is the signed or unsigned type corresponding to the effective type of the object,
• a type that is the signed or unsigned type corresponding to a qualified version of the effective type of the object,
• a type with the same representation and alignment requirement as the effective type of the object,
• the type of any member of any complete union type with a member having one of the aforementioned types,
• an aggregate or union type that includes one of the aforementioned types among its members (including, recursively, a member of a subaggregate or contained union), or
• a character type.

Finally, I have always been somewhat bothered by the fact that the penultimate bullet of §6.5¶7 is not symmetrical. The only sense I have ever been able to make of that bullet was that an assignment to a struct might "kill" or overwrite the value of an object of a type contained by the struct. But of course the same is true the other way around as well; an assignment to an int may also invalidate the cached value of a struct containing an int.

In any event, it seems that the bullet we already have is superfluous. Struct assignment clearly implies assignment to all contained objects, and therefore to objects of all the contained types. It is actually the "nested" access which may do the aliasing.

Perhaps instead we really need to say something about the complementary case, i.e. that the value of an aggregate can modified "piecemeal." Of course we all know that to be the case, but where does the standard say so?