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).
> +@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.
> +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.
--
Joseph S. Myers
[email protected]
