> On Jul 23, 2025, at 03:30, Kees Cook <k...@kernel.org> wrote:
> 
> 
> How would GCC want to define the syntax for expressions here? I still
> think it should be possible to wire up something that matches it in
> Clang, even if it is a "redundant" syntax within Clang (i.e. Clang can
> support 2 way to handle expressions, GCC has 1, and Linux will use the
> common way).

If that’s acceptable, in GCC alias, we have agreed on the following compromised 
solution
after a long and thorough discussion based on one of Bill’s proposal:

1. For a lone identifier that refers to a structure field, keep the current 
counted_by syntax as FAM:
   
counted_by (identifier)

struct s {
  int len;
  int *buf __attribute__((counted_by(len))); // this “len” continues to be 
member ‘len’.
};

 2. For simple expressions inside the counted_by attribute, a new attribute 
will be provided

counted_by_exp (simple expression)

Inside this simple expression, forward declarations will be used to resolve the 
following two issues:

A. Structure-level scoping that does not exist in C language;
B. Fields that are declared after the pointer field. 

For example:

constexpr int len = 20;
constexpr int scale = 4;
struct s {
  int scale; 
  int *buf __attribute__((counted_by_exp(int scale; int len; len * scale)));   
     // len and scale should be the fields inside the structure due to the 
forward declarations
  int len;
};


I noted that the forward declarations has been strongly rejected in the 
discussion inside CLANG, but
didn’t find and understand what’s the root reason for the “strong rejection”. 


> 
> The two things I've seen proposed during all of these discussions that
> look like they should be workable are either:
> 
> 1) making expression-using attributes _struct_ attributes, not struct
> _member_ attributes. (i.e. parsing of the struct has ended)

This should resolve the issue B I listed in the above, but still cannot resolve 
the scoping issue.
If there is a conflict between a global and a field, which one to choose?

> 
> 2) using a callback for expressions (no late parsing needed)

I don’t like this approach due to following reasons:
1. both user interface and compiler interface are not friendly;
2. Arbitrary function call might be abused by users later;
3. It’s very hard to be developed to a feature that can be standardized in the 
future. 

> 
> I'm well aware that Apple's implementation will not do either of these,
> but I'm confident Clang can support the additional syntax -- it should
> be possible to provide both, especially since it would be a "GCC
> compatibility" issue. :)

If Clang can provide a GCC compatible counted_by_exp attribute, then the 
problem can be 
Resolved for linux kernel.

That’s good news.

Qing
> 
> -Kees
> 
> -- 
> Kees Cook

Reply via email to