Hi folks, I wanted to share some updates from our WG14 meeting in Brno, where we presented our proposal on dependent attributes.
# Our Proposal We presented N3656 (www.open-std.org/jtc1/sc22/wg14/www/docs/n3656.pdf), which introduces "Dependent Attributes" as a new category of attributes that need to reference other program entities (with __counted_by(len) as the primary example). The proposal defines two key behaviors for name lookup: Forward lookup (delayed parsing) to reference not-yet-declared structure members or parameters Direct member access using identifier names without prefixes # Voting Results After discussions, we put forward three questions to the committee: 1. Name lookup mechanism: Is WG14 in favor of the name lookup mechanism for dependent attributes proposed in N3656? Result: Weak in favor. More members voted in favor than against. Committee feedback indicated a desire for well-defined restriction rules for expressions within __counted_by and similar attributes to minimize potential issues with delayed parsing. 2. Diagnostics for name conflicts: Is WG14 against diagnosing name conflicts for array parameter size? int size; // name conflict - diagnose as potential mistake void foo(int arr[size], int size); Result: Strong direction for adding diagnostics. MISRA C already forbids such shadowing as error-prone. These diagnostics will help us understand how frequently this pattern occurs and its impact. 3. Forward declaration approach: Does WG14 want to see something along the lines of N3433 (www.open-std.org/jtc1/sc22/wg14/www/docs/n3433.pdf)? Result: No consensus. More members voted against this approach, despite previous "along the lines" support. Several members changed their position due to the delayed parsing alternative and Clang's opposition to the forward declaration approach. # Next Steps Based on this feedback, we're proceeding with: ## Specification work: - Formalize restrictions for expressions in dependent attributes in the revised proposal - Submit a standard proposal specifically for bounds attributes (N3656 focused on name lookup rules rather than specific attributes) ## Implementation in Clang: - Add diagnostics for name conflicts in array parameter size, potentially proposing it as ill-formed if results support it. - Continue open-sourcing -fbounds-safety for features not dependent on complex expressions in counted_by. This will still allow adopting the annotation in most of the use cases. - Implement the proposed name lookup rule under an experimental flag with formalized restrictions to verify the approach in Clang. ## 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. 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] <mailto:[email protected]>
