Am Donnerstag, dem 24.07.2025 um 14:25 -0700 schrieb Bill Wendling:
> On Thu, Jul 24, 2025 at 8:03 AM Martin Uecker <ma.uec...@gmail.com> wrote:
> > Am Donnerstag, dem 24.07.2025 um 14:08 +0000 schrieb Aaron Ballman:
> > > On Wed, Jul 23, 2025 at 8:38 PM Martin Uecker <ma.uec...@gmail.com> wrote:
...
> >
> > TBH, I am not terrible convinced about this argument.
> >
> > If I understood it correctly, the late parsing design seems to make
> > no distinctions between which identifiers is used, the local or
> > the global one and just prefers the local one if it exists, possibly
> > giving a warning if there is also a global one.
>
> Yes...kinda. The order of name lookup would essentially be: field
> within a struct, any non-global scope, global scope. (As Kees pointed
> out, there would be times when we need to support function calls and
> counts in sub-structs, but those are handled by this convention.) The
> only part of this ordering that *isn't* part of normal C identifier
> resolution is the "field within a struct" part.
>
The other big thing were it diverges from normal C identifier lookup
(and also C++ for most cases) which you miss in the description above,
is that it would pick up an identifier that comes later in the scope.
The following code prints 10 and not 20. I think this is the much
bigger and more severe divergence.
int main()
{
int n = 10;
{
printf("%d\n", n);
int n = 20;
}
}
> The question about
> whether or not this would cause "confusion" to C programmers isn't
> completely settled, however Apple says that they have a lot of users
> and have yet to run into anyone who was confused by it. While just
> anecdotal evidence, it's a good indicator that people would use the
> feature "correctly."
I hope I get to see some more information about the context the
data Apple has.
But the story of my life at the moment is about disagreeing with
C++ programmers who tell me how C is written but who actually only
often have some very imited experience writing C. So I generally
be sceptical about statements that do not match my experience.
(I use size expressions in C in prototypes a *lot*, so all this
talk about how this is error prone simply does not match my
personal experience.)
> >
...
> > I think it is generally a challenge to support. One could certainly
> > store away the tokens and parse them later (this is certainly doable),
> > but it adds a lot of issues because you need to add a lot of constraints
> > for things which should then not be allwoed. And it is still not an
> > acceptable solution for size arguments in C.
> >
> > .N would work here if you combine with a rule such as ".N" is always
> > converted to "size_t". Or you require an explicit cast if is different
> > to "size_t" .
>
> Does this mean that the example above would be treated essentially like:
>
> void func(char *buffer __counted_by((size_t).N * sizeof((size_t).N)), int
> N);
>
> ?
Nobody has devised a full specification for .N yet, that would support
arbitrary expressions There are several possibilities. Treating it as
size_t would be one option, but probably not a very good one.
One option which might be attractive is to treat it as int which would
cover all types that have integer promotion, and require the user to add
a cast if it comes later and is something else.
One question here is also if you really want an unsigned type when
you compute a bound, because you might get wraparound. This makes
we wonder how this expressions would look like in practice. Maybe
you casts anyway.
The original idea was to first support it only for a single
identifier [.N] and maybe just special expressions such as [.N + 3]
in which case the type may not be relevant because you want to treat
this specially anyway.
Martin
