ISO Aliasing rules question

[law@redhat.com]

In message <Pine.LNX.4.33.0302220019400.4365-100000@kern.srcf.societies.cam.ac.
uk>, "Joseph S. Myers" writes:
 >> I asked myself also repeatedly similar things.  Is 'a->d' a whole object
 >> or not?  If yes, then 'a->d' and 'b->d' alias because they have the same
 >> type.  I not, i.e. they are only part of the objects *a and *b, then they
 >> can not alias, because as you notice 'struct s1' and 'struct s2' are not
 >> compatible types as defined in 6.2.7 #1.
 >
 >The basic "what is an object?" question is discussed in Nick Maclaren's
 >discussion with a title something like that, posted to the WG14 reflector
 >some time ago, required reading for anyone contemplating such issues; ask
 >him for a copy if you don't have one.
Do you have a contact address for Nick?  I wandered

 http://std.dkuug.dk/jtc1/sc22/wg14

But couldn't find a reference to that paper.


 >In this case, a (in main) has declared type (so effective type) struct s1,
 >so _if_ the structure is the relevant object then access through the type
 >struct s2 would be undefined.  But if you declared a as double, and then
 >cast &a to each pointer type, then I think all accesses in f would be
 >legitimate: an object of effective type double is accessed through
 >structure types with an element of that type.
But in "f" we have the following

  a->d = 1.0
  return b->d + 1.0;

According to an earlier message, that is just "shorthand" for:

  (*a).d = 1.0
  return (*b).d + 1.0

Which seems to me to clearly access "a" and "b" first, then their
appropriate field, which it would seem to me to run afoul of the
aliasing rules.

FWIW, the tree-ssa code uses the model above.  First you indirect the
pointer, then you look at the appropriate field.

 >DR#236 discusses some problems with the type-based aliasing rules that are
 >far from resolved.  A proper resolution of such problems requires the
 >underlying issues with the concept of an object to be resolved first.
Yup, but I didn't see how DR236 directly related to this issue.  Or maybe
I just didn't think about it hard enough :-)

jeff