Hi Martin, On Sat, Jul 27, 2024 at 12:59:34AM GMT, Martin Uecker wrote: > Am Samstag, dem 27.07.2024 um 00:26 +0200 schrieb Alejandro Colomar: > > On Sat, Jul 27, 2024 at 12:03:20AM GMT, Martin Uecker wrote: > > > > 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 > > > > Hi Martin, > > > > I guess that's prior art enough to make this UB in ISO C. Is there any > > paper for this already? Does any of your paper cover that? Should I > > prepare one? > > > > What do you mean by "this"? Adding UB. > Adding UB would likely see a lot > of opposition, But UB allows for safer code. It's the lack of UB what reduces the quality of diagnostics, which results in worse code. I understand it will see opposition, so we better wait for the path to be prepared (i.e., n2906 already merged before presenting a paper), but once that's done, I'd try to add UB. > even where this could enable run-time checks. (And build-time too.) > N2906 would make > > int foo(char f[4]); > int foo(char f[5]); > > a constraint violation (although having those types be incompatible > could also cause UB indirectly, this would not be its main effect). > > So I think brining a new version of this paper forward would be > a possible next step, addressing the issues raised in the past. Yeah, that would be a good next step. And when the array type is part of the function type, it'll be easier to convince that [n] can only mean [n]. Have a lovely day! Alex > Martin > -- <https://www.alejandro-colomar.es/>
Attachment:
signature.asc
Description: PGP signature
