Hi Joseph, I'd like to ping about this thread.
Cheers, Alex On Tue, Aug 19, 2025 at 12:44:29PM +0200, Alejandro Colomar wrote: > 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/> -- <https://www.alejandro-colomar.es> Use port 80 (that is, <...:80/>).
signature.asc
Description: PGP signature
