Formal definition of restrict

[Hallvard B Furuseth]

6.7.3.1p3 from "Formal definition of restrict" says

In what follows, a pointer expression E is said to be based on object
P if (at some sequence point in the execution of B prior to the
evaluation of E) modifying P to point to a copy of the array object
into which it formerly pointed would change the value of E.122) Note
that "based" is defined only for expressions with pointer types.

This means, as far as I can tell, that given
float *r = foo();
int *q = bar(), *restrict p = q;
expression E1: (p == q ? NULL : r)
expression E2: (p == q ? NULL : (r = NULL))
then E1 is based on p but E2 is not. Is that right? And intentional?
Or is the easier-to-read informal note 122 (117 in C99) more correct
than the formal definition?

"122) In other words, E depends on the value of P itself rather than on
the value of an object referenced indirectly through P. For example,
if identifier p has type (int **restrict), then the pointer
expressions p and p+1 are based on the restricted pointer object
designated by p, but the pointer expressions *p and p[1] are not."

--
Hallvard

[lawrenc...@siemens.com]

Hallvard B Furuseth <h.b.fu...@usit.uio.no> wrote:
>
> This means, as far as I can tell, that given
> float *r = foo();
> int *q = bar(), *restrict p = q;
> expression E1: (p == q ? NULL : r)
> expression E2: (p == q ? NULL : (r = NULL))
> then E1 is based on p but E2 is not. Is that right? And intentional?

Yes, I believe that is correct and intentional. Note, however, that in
the second case, the expression "r" is based on p even though the
containing expression (E2) is not.
--
Larry Jones

I sure like summer vacation. -- Calvin

[christian.bau]

On Jul 6, 6:18 pm, Hallvard B Furuseth <h.b.furus...@usit.uio.no>
wrote:

I think the definition of "based on" was somehow difficult to get
right, and it will include some cases that were not intended.

"restrict *" has two effects: For the compiler writer, there are cases
where a compiler can assume that two pointers don't point to the same
object, or where a compiler can assume that an object isn't modified.
For the application programmer, there are cases where accessing the
same object through two different pointers invokes undefined behaviour
and must be avoided, and where modifying an object invokes undefined
behaviour and must be avoided.

If the definition of "based on" is unclear in some situation, then the
compiler cannot make these assumptions. In other words, the presence
of the "restrict" keyword can only be used in situations that are
clear to the compiler. On the other hand, the application writer only
must use "restrict *" in situations that are clear.

For purposes of optimisation, a compiler would have to split pointer
expressions in the three categories "based on P", "not based on P",
and "don't know". If you ask "is E based on P or not"? then putting E
into the category "don't know" is the safe thing to do.