> On Jul 23, 2025, at 03:30, Kees Cook <[email protected]> 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