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

[Alejandro Colomar]

On Fri, Jul 26, 2024 at 09:22:42PM GMT, Joseph Myers wrote:
> On Fri, 26 Jul 2024, Alejandro Colomar via Gcc wrote:
> 
> > > See reflector message SC22WG14.18575, 17 Nov 2020 (the former convenor 
> > > replying when I asked about just that paper).
> > 
> > Where can I find reflector messages?
> 
> https://www.open-std.org/jtc1/sc22/wg14/18575

Thanks!

> 
> > And another one to propose that [n] means the same as [static n] except
> > for the nonnull property of static.
> 
> I'm not convinced that introducing extra undefined behavior for things 
> that have been valid since C89 (which would be the effect of such a change 
> for any code that passes a smaller array) is a good idea - the general 
> mood is to *reduce* undefined behavior.

While [n] has always _officially_ meant the same as [], it has never
made any sense to write code like that.  Unofficially, it has always
meant the obvious thing.

Maybe if GNU C compilers (GCC and Clang) add it first as an extension,
adding diagnostics, it would help.

Does anyone know of any existing code that uses [n] for meaning anything
other than "n elements are available to the function"?

Functions that specify [n] most likely (definitely?) already mean that
n elements are accessed, and thus passing something different than n
elements results in UB one way or another.  Having the compiler enforce
that via diagnostics and UB is probably an improvement.

Cheers,
Alex

> 
> -- 
> Joseph S. Myers
> josmyers@redhat.com
> 

-- 
<https://www.alejandro-colomar.es/>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/gcc/attachments/20240726/ccc82783/attachment.sig>