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@xxxxxxxxxx > -- <https://www.alejandro-colomar.es/>
Attachment:
signature.asc
Description: PGP signature
