Jakub, Thank you for the comments.
> On Apr 2, 2025, at 02:48, Jakub Jelinek <ja...@redhat.com> wrote: > > On Tue, Apr 01, 2025 at 05:13:46PM -0700, Bill Wendling wrote: >> On Tue, Apr 1, 2025 at 8:29 AM Martin Uecker <uec...@tugraz.at> wrote: >>> Am Dienstag, dem 01.04.2025 um 15:01 +0000 schrieb Qing Zhao: >>>>> On Apr 1, 2025, at 10:04, Martin Uecker <uec...@tugraz.at> wrote: >>>>> Am Montag, dem 31.03.2025 um 13:59 -0700 schrieb Bill Wendling: >>>>>>> I'd like to offer up this to solve the issues we're facing. This is a >>>>>>> combination of everything that's been discussed here (or at least that >>>>>>> I've been able to read in the centi-thread :-). >>>>> >>>>> Thanks! I think this proposal much better as it avoids undue burden >>>>> on parsers, but it does not address all my concerns. >>>>> >>>>> >>>>> From my side, the issue about compromising the scoping rules of C >>>>> is also about unintended non-local effects of code changes. In >>>>> my opinion, a change in a library header elsewhere should not cause >>>>> code in a local scope (which itself might also come from a macro) to >>>>> emit a warning or require a programmer to add a workaround. So I am >>>>> not convinced that adding warnings or a workaround such as >>>>> __builtin_global_ref is a good solution. >> >> To clarify, I'm not in favor of adding a generalized new scoping rule >> to C, but only for identifiers in attributes. From what I've seen in > > There are existing attributes which support general expressions in their > arguments, e.g. the assume attribute, https://gcc.gnu.org/onlinedocs/gcc/Statement-Attributes.html#index-assume-statement-attribute " assume The assume attribute with a null statement serves as portable assumption. It should have a single argument, a conditional expression, which is not evaluated. If the argument would evaluate to true at the point where it appears, it has no effect, otherwise there is undefined behavior. This is a GNU variant of the ISO C++23 standard assume attribute, but it can be used in any version of both C and C++. int foo (int x, int y) { __attribute__((assume(x == 42))); __attribute__((assume(++y == 43))); return x + y; } y is not actually incremented and the compiler can but does not have to optimize it to just return 42 + 42;. “ The expressions inside the assume attribute are evaluated as a regular expressions by following C’s scoping rules. > OpenMP attributes etc. Those definitely > shouldn't change behavior if some new behavior for identifier lookup in > attributes > is added. > Many others do support identifiers as their arguments (e.g. mode attribute, > 2 argument malloc attribute, ...). Those can't change behavior either. > > I think using either a predefined identifier or self-declared one is the > only reasonable way to go (whether it represents something like this pointer > in C++ or in the latter case possibly forward declaration of the member), > otherwise > it will be hard to understand for users and very much error prone. So, my understanding of your above is: Either 1. The approach to add a new keyword, such as, __self, which represent the similar concept of “this” in C++; Or 2. The approach to add the forward declaration of the member, such as: __counted_by(size_t len; len + PADDING) Is good? Yes, I agree, and personally I prefer 1, I think it’s the best solution. And the implementation in GCC FE might be the cleanest one. However, I am okay with 2 as a compromise approach. thanks. Qing > > Jakub
