On Wed, Nov 07, 2007 at 02:30:44AM +1100, skaller wrote: > > The claim was, in the context of the example given, "Without strict > > aliasing being enabled, the compiler can't assume that that the assignment > > 'p[i] = 1' won't change 'p'". > > In this case I think it can. More precisely, IF the assignment > changes p, another rules is broken (1 isn't a pointer), and > all bets are off, so the compiler can go ahead and assume > p can't be modified -- on an amd64 anyhow (since int isn't > intptr_t).
You are implicitly assuming strict aliasing. Strict aliasing means that you reject a possible aliasing based on the type, as you are doing here (1 isn't a pointer). If you turn it off, the compiler cannot make that assumption: the user might be doing something strange with casts. Now it appears that you want to make some kind of intermediate assumption (semi-strict aliasing?), where pointers of different types are allowed to alias while ints can't alias with pointers. But that's a rule you're making up yourself, without any support in the standard or in the GCC implementation.
