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:

quoted

On Fri, 26 Jul 2024, Alejandro Colomar via Gcc wrote:

quoted

quoted

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!

quoted

quoted

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

quoted

-- 
Joseph S. Myers
josmyers@redhat.com