Am Dienstag, dem 29.07.2025 um 13:49 +0000 schrieb Qing Zhao:
>
> > On Jul 28, 2025, at 17:39, Martin Uecker <ma.uec...@gmail.com> wrote:
> >
> > Am Montag, dem 28.07.2025 um 20:48 +0000 schrieb Qing Zhao:
> > >
> > > > On Jul 28, 2025, at 16:09, Martin Uecker <ma.uec...@gmail.com> wrote:
> > > >
> > > > >
...
> > > > > Ex 6)
> > > > > constexpr int n = 10;
> > > > > struct s {
> > > > > int *__counted_by_expr(n + 1) ptr; // resolves to global `n`; okay,
> > > > > no matching member name
> > > > > };
> > > > >
> > > > > Or in case, people prefer forward declaration inside
> > > > > `__counted_by_expr()`, the similar rule can apply to achieve the same
> > > > > goal.
> > > > >
> > > >
> > > > Thank you Yeoul!
> > > >
> > > > I think it is a reasonable compromise.
> > >
> > > Yes, I agree. -:)
> > >
> > > It adds two new keywords in both C and C++ (__self and __global_ref) to
> > > explicitly mark the scopes for the variables inside the attribute.
> > > will definitely resolve the lookup scope ambiguity issue in both C and
> > > C++.
> > >
> > > However, it will not resolve the issue when the counted_by field is
> > > declared After the pointer field.
> > > So, forward declarations is still needed to resolve this issue, I think.
> >
> > Yes, forwards declarations are this simplest solution.
> >
> >
> > Another idea I mentioned before is to let __self.N have type
> > int, and then emit an error later if it has a type that
> > would change the type / meaning of the immediate
> > parent expression.
>
> Yes, this is reasonable too.
>
> However, one of the major issue with it is, the user has to change the type
> of all the counted_by field to “int”. Not sure whether this is easy to do or
> not
> for a large application.
I agree that this would not make sense. Sorry, I did not explain
this idea well.
The idea is that we parse assuming it has type "int", but then it is
ok to have a different type as long as this would not invalidate or
previous analysis. Only when the *parent* expression would change
type, then this is an error later when we know the real type.
So for example it can have type "bool", "char", "short" because these
would promote to an integer, so inserting them for __self.N would
not invalidate or previous analysis that was done assuming it was
an "int". It turns out that there are many other cases where the
type does not matter (e.g. see below) and which would just work.
Martin
>
> Qing
> >
> > This would allow all of the following:
> >
> > struct foo {
> > char * __counted_by_expr(__self.N) buf;
> > int N;
> > };
> > struct foo {
> > char * __counted_by_expr(__self.N + 1L) buf;
> > long N;
> > };
> > struct foo {
> > char * __counted_by_expr(__self.N * 2) buf;
> > int N;
> > };
> > struct foo {
> > char * __counted_by_expr(__self.N + 2) buf;
> > char N;
> > };
> > struct foo {
> > char * __counted_by_expr(__self.N + .M) buf;
> > int N; int M;
> > };
> > struct foo {
> > char * __counted_by_expr((int)__self.N) buf;
> > double N;
> > };
> > struct foo {
> > char * __counted_by_expr(3 * sizeof(__self.buf2)) buf;
> > char buf2[5];
> > };
> > struct foo {
> > char * __counted_by_expr(((struct bar *)__self.x)->z) buf;
> > struct bar *x;
> > };
> >
> >
> > It would *not* allow:
> >
> > struct foo {
> > char * __counted_by_expr(__self.N + 1) buf;
> > long N;
> > };
> > struct foo {
> > char * __counted_by_expr(__self.x->z) buf;
> > struct foo *x;
> > };
> >
> >
> > But in this case you would get an explicit error:
> >
> > xyz:13.4: Type of `__self.N' needs to be known. Did you forget to
> > add a cast `(long)__self.N'?
> >
> >
> >
> > Martin
> >
> >
> >
> >
> >
> >
>
