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. And the declarations *aren't* conflicting under current language semantics. 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.) > > N3605 is definitely relevant even with a single declaration and no > > composite types, because it may determine what's valid regarding the > > parameter name in parentheses or returned by _Generic. > > I don't see the relevance. Could you show a piece of code which could > change meaning? > > I only see that slight differences in what's accepted or not could > happen, but that's something we should be able to adapt, just as we'd > need to adapt many other places. I don't see it being of special > relevance here. > > That proposal (n3605) is also not polished enough for merging, from what > I can see, so I don't see why we should wait indefinitely. We should actually understand the desired semantics for a feature - including its interactions with other features, both standard and extensions - before considering it for inclusion in GCC. Going slow with new features is *good*, not bad. Working out underlying infrastructure first in the standard is good, not bad. We've seen the problems plenty of times with features rushed into either implementation or the standard without adequate consideration of the trickier parts of their semantics and interaction with other features. The *hundreds* of ballot comments on C23 (CD1, CD2, DIS) indicated plenty of problems with trying to rush too many features into the standard too quickly (as well as with papers being edited into the working draft inaccurately). Given the flood of proposals for C2y, a sensible way to prune things would be to put aside any proposals or ideas for proposals that run into issues with the underlying semantic foundations, until the issues with those foundations have been cleaned up. -- Joseph S. Myers josmy...@redhat.com
