Hi Joseph, On Fri, Jul 26, 2024 at 04:24:14PM GMT, Joseph Myers wrote: > 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). I don't see why it should not apply to void*. memcpy(3) should get this attribute: [[alx::restrict(1)]] [[alx::restrict(2)]] void *memcpy(void *dst, const void *src, size_t n); The index to which the text above refers is that '(1)' and '(2)'. > 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), Agree. I think arrays should be fixed in C. n2906 is a good step towards that. Thanks Martin! :) BTW, the author of n2529 didn't follow up, right? I'd like that in, so I'll prepare something after n2906 is merged. Martin, would you mind pinging me about it? For what this [[alx::restrict]] proposal is concerned, I'd wait after n2906 is merged for proposing that extension. > and even > N2906 wouldn't help for the VLA case. I'd basically propose that [3] or [n] means the same as [static 3] and [static n], except for the nonnull implications of static. Is there any such paper? I'm interested in presenting one for that. Maybe it would also be interesting to wait after n2906 for that too. > > [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[*]); Yeah, that should be fixed in the standard. I'll keep that extension of restrict out of a proposal until array parameters are fixed in that regard. > (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. Yup. > 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? As I said in reply to Branden's response, it seems Dennis's concern was that the noalias proposal was a qualifier, which admittedly makes little sense (very much like the problems restrict has, but applied to the pointee, which makes them much worse). That in fact led me recently to think that an _Optional qualifier (similar to Clang's _Nullable) as is being proposed at the moment in n3222 is similarly DOA. Those qualities of pointers are attributes, which cannot be specified in the type system. Have a lovely night! Alex > > -- > Joseph S. Myers > josmyers@xxxxxxxxxx -- <https://www.alejandro-colomar.es/>
Attachment:
signature.asc
Description: PGP signature
