The whole point of restrict
is to promise accesses through one pointer don't alias another. That said, there are examples where overlapping memory addresses wouldn't imply aliasing. For example:
int* arr_ptr0 = &arr[0];
int* arr_ptr1 = &arr[1];
for (int i=0;i<10;++i) {
*arr_ptr0 = *arr_ptr1;
arr_ptr0 += 2;
arr_ptr1 += 2;
}
The thing is, these pointers actually do point to overlapping memory! For this particular example, guides like this say, e.g.:
It is valid . . . to point into the same array object, provided the range of elements accessed through one of the pointers does not overlap with the range of elements accessed through the other pointer.
My question is: What granularity is "elements"?
For example, suppose I have an array of type struct Foo
. Do I really need to ensure that I don't access the same range of elements (Foo
s), even if the parts I access are disjoint? Here's a simple, scalar example:
struct Foo { int i; float f; };
void f(struct Foo*restrict foo0, struct Foo*restrict foo1) {
foo0->i = 6;
foo1->f = 19.0f;
}
void g(struct Foo* foo) {
f(foo,foo); /* problem? */
}
You can run into similar issues with pointers to different types (e.g. char
vs. int
), but perhaps the structure example above is more clear.
ptr1[a] .. ptr1[b]
(a < b) andptr2[c] .. ptr2[d]
(c < d) and any of the addresses in the first range are the same as any of the address in the second range, the restrict constraint is violated. – Scissurerestrict
-qualified pointer's lifetime. – Nathalienathan