Hi Jens, Joseph,
On Wed, Aug 07, 2024 at 05:30:13PM GMT, Jens Gustedt wrote:
> Hi
>
> Am 7. August 2024 17:05:48 MESZ schrieb Joseph Myers <josmy...@redhat.com>:
> > On Wed, 7 Aug 2024, Alejandro Colomar wrote:
> >
> > > +@node Length
> > > +@section Determining the Length of Arrays
> > > +@cindex lengthof
> > > +@cindex length
> > > +@cindex array length
> > > +
> > > +The keyword @code{__lengthof__} determines the length of an array
> > > operand,
> > > +that is, the number of elements in the array.
> > > +Its syntax is just like @code{sizeof}.
> > > +The operand must be a complete array type.
> >
> > I think you mean the operand must be *an expression whose type is a
> > complete array type* or *a type name for a complete array type*. The
> > wording you have suggests only type names, you need to be clear about both
> > kinds of operands being possible (and include examples for them).
I've written the following for v6:
-Its syntax is just like @code{sizeof}.
-The operand must be a complete array type.
+Its syntax is similar to @code{sizeof}.
+The operand must be a complete array type or an expression of that type.
+For example:
+
+@smallexample
+int a[n];
+__lengthof__ (a); // returns n
+__lengthof__ (int [7][3]); // returns 7
+@end smallexample
+
> >
> > > +@smallexample
> > > +__lengthof__ (int [7][n++]); // constexpr
> > > +__lengthof__ (int [n++][7]); // run-time value
> > > +@end smallexample
> >
> > I don't think using "constexpr" to mean "constant expression" is a good
> > idea, they're different things.
>
> It should actually state "integer constant expression", I think. the nuance
> is probably important
Agree.
>
>
> > > +void
> > > +incomplete (int p[])
> > > +{
> > > + unsigned n;
> > > +
> > > + n = __lengthof__ (x); /* { dg-error "incomplete" } */
> > > +
> > > + /* We want to support the following one in the future,
> > > + but for now it should fail. */
> > > + n = __lengthof__ (p); /* { dg-error "invalid" } */
> >
> > This seems to be the only test you have for a non-array operand. I'd
> > expect such tests (both for type name operands and for expression
> > operands) covering cases that we *don't* want to support in future, not
> > just this one that we would like to be supportable in future.
> >
> > I don't see any tests for the constraints on external definitions from
> > 6.9.1 that we discussed - that referenced to undefined internal linkage
> > identifiers are OK inside __lengthof__ returning a constant (both
> > constant-length arrays of non-VLA and constant-length arrays of VLA) but
> > not in the cases where __lengthof__ is evaluated.
> >
I think I've added them for v6. (Please let me know if anything is
still untested there.) I'll publish v6 after I test for regressions.
Have a lovely night!
Alex
--
<https://www.alejandro-colomar.es/>
signature.asc
Description: PGP signature
