Some comments on the documentation part.
(Hopefully, this time my quoting format is good, I checked the email
sent back to myself, no formatting issue, but when I checked the emails
in the archive,
https://gcc.gnu.org/pipermail/gcc-patches/2024-August/659593.html,
yst, I see the quoting format issue you mentioned, adjusted my mail client
setting,
hopefully this time it’s good)
> On Aug 6, 2024, at 08:22, Alejandro Colomar <a...@kernel.org> wrote:
>
> diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
> index 0b572afca72..6e1d302150d 100644
> --- a/gcc/doc/extend.texi
> +++ b/gcc/doc/extend.texi
> @@ -10391,6 +10391,33 @@ If the operand of the @code{__alignof__} expression
> is a function,
> the expression evaluates to the alignment of the function which may
> be specified by attribute @code{aligned} (@pxref{Common Function Attributes}).
>
> +@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.
What’s the behavior when the array operand is a VLA, or a flexible array member?
Should these be clarified in the documentation part?
> +The operand is not evaluated
> +if the top-level length designator is an integer constant expression;
> +and it is evaluated
> +if the top-level length designator is not an integer constant expression.
Can you add small examples to clarify the above?
> +
> +XXX: Do we want to document the following? I think so.
> +XXX: It would prevent users from relying on __lengthof__
> +XXX: for distinguishing arrays from pointers.
> +XXX: I don't want users to complain in the future
> +XXX: if this doesn't report errors on function parameters anymore
> +XXX: and that breaks their assumptions.
> +In the future,
> +it might also accept a function parameter with array notation,
> +an incomplete array whose length is specified by other means,
> +such as attributes,
> +or other similar cases.
For incomplete array (for example, flexible array members), as I mentioned in
another email:
https://gcc.gnu.org/pipermail/gcc-patches/2024-August/659478.html
I think that it’s better to wait the Length information is finally integrated
into TYPE.
thanks.
Qing
> +
> @node Inline
> @section An Inline Function is As Fast As a Macro
> @cindex inline functions
