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 > > josmy...@redhat.com > > >
