On 6/17/07, Richard Kenner <[EMAIL PROTECTED]> wrote:
> > > > So if I have > > > > struct foo {int x; float y; } bar; > > > > > > But if you add > > > > > > struct foo *foop = &bar. > > > > > > foop->x = 5. > > > > > > It can, even though we *claim* X is nonaddressable. > > > > Which can what exactly? > > It can be addressed, as i've shown above. foop is a pointer to &bar.x > in the above case.No, it's a pointer to bar. It contains the same *value* as a pointer to
bar.x is "nonaddresable" in the sense that any pointer that refers to memory contained in it can't be of the type of the field (int) and hence can't be of its alias set, but must be of the type of bar (struct foo) and hence of *that* alias set. > The reality is that a pointer to it's parent can legally access it, so > their alias sets should conflict. Which alias sets? How can a pointer to int conflict with a pointer to bar if X is nonaddressable?
That is not the example case we have given where this breaks. The case where it breaks is exactly the case i have shown you. We have a pointer to a structure, and because you have not recorded the type's alias relationships properly, we claim derferences that are offsetted from the structure can not access the field. This is a direct consequence of trying to use the parent's alias set for that of the child type, instead of creating a new alias set.
