Re: n3294 - The restrict function attribute as a replacement of the restrict qualifier

[Joseph Myers <josmyers@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 3092 bytes --]

On Wed, 10 Jul 2024, Alejandro Colomar via Gcc wrote:

>    6.7.13.x The restrict function attribute
>      Constraints
>             The restrict attribute shall be applied to a function.
> 
>             A 1‐based index can be specified in an  attribute  argument
>             clause,  to  associate the attribute with the corresponding
>             parameter of the function, which must be of a pointer type.

It's more appropriate to say "shall", and you need a requirement for the 
pointer to be a pointer to a complete object type (it makes no sense with 
function pointers, or void).  That is, something like "If an attribute 
argument clause is present, it shall have the form:

  ( constant-expression )

The constant expression shall be an integer constant expression with 
positive value.  It shall be the index, counting starting from 1, of a 
function parameter whose type is a pointer to a complete object type.".

(That might not quite be sufficient - there are the usual questions of 
exactly *when* the type needs to be complete, if it's completed part way 
through the function definition, but the standard already doesn't tend to 
specify such things very precisely.)

>             (Optional.)   The argument attribute clause may be omitted,
>             which is equivalent to specifying the  attribute  once  for
>             each parameter that is a pointer.

For each parameter that is a pointer to a complete object type, or should 
there be a constraint violation in this case if some are pointers to such 
types and some are pointers to other types?

>             If the number of elements is specified with array  notation
>             (or  a compiler‐specific attribute), the array object to be
>             considered for aliasing is a sub‐object of the original ar‐
>             ray object, limited by the number  of  elements  specifiedr
>             [1].

This is semantically problematic in the absence of something like N2906 
(different declarations could use different numbers of elements), and even 
N2906 wouldn't help for the VLA case.

>      [1]  For the following prototype:
> 
>                  [[restrict(1)]] [[restrict(2)]]
>                  void f(size_t n, int a[n], const int b[n]);

That declaration currently means

  void f(size_t n, int a[*], const int b[*]);

(that is, the expression giving a VLA size is ignored).  It's equivalent 
to e.g.

  void f(size_t n, int a[n + foo()], const int b[n + bar()]);

where because the size expressions are never evaluated and there's no time 
defined for evaluation, it's far from clear what anything talking about 
them giving an array size would even mean.


I know that "noalias" was included in some C89 drafts but removed from the 
final standard after objections.  Maybe someone who was around then could 
explain what "noalias" was, what the problems with it were and how it 
differs from "restrict", so we can make sure that any new proposals in 
this area don't suffer from whatever the perceived deficiencies of 
"noalias" were?

-- 
Joseph S. Myers
josmyers@redhat.com