Re: ANSI-strict pointer aliasing rules

Martijn van Oosterhout <kleptog(at)svana(dot)org> writes:
> That's right, except I read "object", not "primative type". The
> question revolves a bit around what an object is. This discussion on
> the GCC lists [1] suggests that the syntax a->b is merely syntactic
> sugar for (*a).b and thus the "object" being accessed is (*a), the type
> of b is not relevent to the decision.

The part of the spec that I'm looking at says

[#7] An object shall have its stored value accessed only by
an lvalue expression that has one of the following types:61)

-- 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,

-- 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.

61)The intent of this list is to specify those circumstances
in which an object may or may not be aliased.

Which wouldn't be especially interesting, except for that footnote
(which in fact is one of only two uses of "alias" in the document;
there isn't any other discussion about aliasing at all).

As I read this, the aliasing rules are driven by the type of the
lvalue being fetched or assigned. Thus, when you fetch or assign a
whole struct, your reading would be correct, but not for a fetch
or assignment of a single struct field.

regards, tom lane