On 9/3/07, Daniel Berlin <[EMAIL PROTECTED]> wrote: > > That said, second, my understanding of restrict, from reading the c99 > standard, is that it is perfectly valid for restrict pointers to alias > each other during *loads*.. IE you can guarantee any restricted > pointer that is stored into can't alias the other restricted pointers. > Those only used for loads can alias each other. > > This comes from 6.7.3.1 #4, which says "During each execution of B, > let L be any lvalue that has &L based on P. If L is used to access > the value of the object X that it designates, and X is also *modiļ¬ed* > (by any means), ... the following requirements apply:...[part about > not being able to point to same object, basically]" > > They even given an example of this (two restricted pointers to arrays > aliasing) happening. > > It this an incorrect reading? I'll happily admit that reading > standards makes my brain hurt, it's worse than reading caselaw, so i'd > love to be wrong. > > I'd also love to simply ignore this part, because i don't believe > anyone who has actually *used* restrict thinks it means anything other > than "this can't alias my other restrict pointers". > > I'm also pretty sure no other compiler implements this restriction > anyway, as it removes a *lot* of useful cases of restrict. We > certainly get it wrong. :)
How does it make a difference? If for two pointers that are only loaded from we say they don't alias I cannot imagine a transformation that would get anything wrong. For example EXAMPLE 2 clearly suggests that not both pointers need to be written to. That is, EXAMPLE 3 is merely to make it defined behavior from a standards point of view, even if it doesn't make a difference in practice. But, IANTL. ;) Richard.
