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

[Martin Uecker]

Am Freitag, dem 26.07.2024 um 23:49 +0200 schrieb Alejandro Colomar via Gcc:
> 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.

Both GCC and Clang already have such diagnostics and/or run-time checks:

https://godbolt.org/z/MPnxqb9h7

Martin


> 
> 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
> > 
>