Am Dienstag, dem 16.09.2025 um 11:39 -0700 schrieb Yeoul Na: > > > ## Seeking Community Input: > > I'd like to hear what the GCC/Clang community thinks about the idea of > specifying formal restrictions for expressions within the attributes to > support delayed parsing. Or should we still seek alternatives to avoid > delayed parsing? Your feedback on this approach would be valuable as we move > forward with the implementation.
I would say so, considering how split the committee was, I currently see no hope for either forward declararions nor delayed parsing to go in. Martin > > Please let me know if you have any questions or thoughts on these next steps. > > Thanks! > Yeoul > > > > On Aug 11, 2025, at 3:30 PM, Joseph Myers <[email protected]> wrote: > > > > On Mon, 11 Aug 2025, Bill Wendling wrote: > > > > > On Thu, Jul 31, 2025 at 12:01 PM Joseph Myers <[email protected]> wrote: > > > > > > > > On Thu, 24 Jul 2025, Aaron Ballman wrote: > > > > > > > > > Question on the .N syntax: I thought I heard that this was something > > > > > GCC could handle, but that it still requires late parsing to ensure > > > > > type information for N is available and that was a problem. e.g., > > > > > > > > > > void func(char *buffer __counted_by(.N * sizeof(.N)), int N); > > > > > > > > The proposed specification for .N in N3188 required the type to be > > > > size_t > > > > when not already declared (it also didn't make .N an expression, only > > > > something that could be used directly inside [], so avoiding the > > > > syntactic > > > > ambiguity with designated initializers). > > > > > > > Has there been any more thoughts on this RFC? > > > > I expect to review N3656 by the time of the Brno meeting of WG14 and to > > send my comments to the WG14 reflector. > > > > -- > > Joseph S. Myers > > [email protected]
