Maybe one additional point about scoping rules. The whole point of scoping is to shield nested code from outside changes. This is what this proposal would break (and the proposed warnings would only mitigate the damage).
One scenario where I find this is problematic are macros. Macros are inserted into code far from where they are defined and often come from libraries. Then having to deal with warnings at completely different places just because a macro uses an identifier internally that also happens to be used and visible at the call site seems problematic to me. The argument that you can then easily change the local name does not apply, because the macro content is not actually local to the call site. It is quite possible that you do not see these issues in the legacy code you are annotating, but I would definitely be concerned about more modern C code and also about the future evolution of the language. Martin Am Freitag, dem 14.03.2025 um 07:16 +0100 schrieb Martin Uecker: > Hi David, > > Am Donnerstag, dem 13.03.2025 um 19:23 -0700 schrieb David Tarditi: > > > > I skip your initiial part. I think this was all discussed before > > (also in WG14) and I still come to different conclusions. Just > two comments: > > ... > > > > The VLA semantics are also problematic. User can side-effect > > variables used in a VLA declaration after the declaration, while > > the declaration is in scope. It is not obvious how to implement > > bounds checking, because the bounds could be gone (invalid). > > It is a design flaw that the declared bounds can become invalid > > while the declaration is in scope. > > Variably modified types do not work like this C. The size > expression is evaluated at the point of declaration. If there > is a variable in it, it is never accessed later and changing it > does not affect the type anymore. > > int len = 1; > char buf[len]; // len is evaluated and the array has size 10 > len = 10; // has no impact on the type of 'buf' > > In fact, one can also have more complicated expressions. > > int len = 11; > char buf[len + 1]; // has size 11. > > and those are also not re-evaluated later. > > > This is exactly how it works in other dependently types languages, > so I do not think one can make the case that C got these semantics > wrong. > > Bounds checking also works already today: https://godbolt.org/z/5P8so1reb > > (although there are still missing pieces which would be important > but which compilers currently do not implement. But for GCC I have > a local branch which adds most of those.) > > > > > > Finally, when you get to nested pointers, the syntax (and typing) > > for VLAs becomes confusing. This isn’t VLAs fault. It is there in the > > original C design. > > Your comments about C's syntax certainly have some truth to them, > but I personally - as a C programmer and teacher - would find > it much worse to add new inconsistent rules to the language > just to be able to write something in a more succinct way > in some specific cases. A programmer would still have to > learn and nderstand the general C syntax and all the existing > rules name lookup rules. > > I do not think adding new inconsistent rules would make the > language simpler and clearer in general, even it it may look > like this when only considering a narrow use case. > > > Martin > >
