Hi Joseph, On Mon, Aug 18, 2025 at 11:19:39PM +0000, Joseph Myers wrote: > On Fri, 15 Aug 2025, Alejandro Colomar wrote: > > > Hi Joseph, > > > > On Thu, Aug 14, 2025 at 10:03:00PM +0000, Joseph Myers wrote: > > > On Thu, 14 Aug 2025, Alejandro Colomar wrote: > > > > > > > And I'm proposing it as a GNU extension, which means we don't even need > > > > to care about what ISO C says about [n]. We, as a quality > > > > implementation, treat it with stronger semantics, which this patch uses. > > > > > > As a GNU extension, it's also necessary to define semantics in the > > > presence of parameter forward declarations. > > > > I'd say that if there are conflicting declarations the behavior is > > undefined. So, if you have [2] and [3], think again what you're doing. > > We shouldn't introduce undefined behavior like that.
It's not really UB. It's a constraint violation: we get (or should get) a diagnostic. Once the diagnostic is ignored, the behavior is undefined, but that's reasonable, IMO. The fact that we don't currently warn is something that should be easy to fix: <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121562> > And the declarations > *aren't* conflicting under current language semantics. They are already conflicting under the GNU C dialect, which diagnoses them. The fact that the ISO C dialect didn't make it a constraint violation is a historic accident that I'd like to get fixed eventually, by just mirroring [static n] (but without the nonnull-ness). > It's the > introduction of this _Countof extension that has significant implications > for the conceptual model of how parameter declarations are handled in C > and introduces such a conflict. > > In this case, we need to document the semantics ourselves in the GCC > manual in a way that makes conceptual sense. (But if some version of > forward declarations were accepted for C2y, then the proposal for array > parameters in _Countof for the C standard would also need updating > accordingly, which might require underlying conceptual changes to array > parameter adjustment in C.) I don't think it makes sense to accept [2] and [3] in a meaningful way. I'd consider it a constraint violation, warn by default, and then leave it as undefined behavior if the programmer decides to ignore it. Or maybe leave it unspecified whether the [2] or the [3] is taken, but I think UB is just easier. Maybe we should move -Warray-parameter from -Wall into default? And why should we define the behavior of what we want to be a constraint violation? Have a lovely day! Alex -- <https://www.alejandro-colomar.es/>
signature.asc
Description: PGP signature
