On Tue, Aug 06, 2024 at 10:38:55PM GMT, Alejandro Colomar wrote: > Hi Qing, > > On Tue, Aug 06, 2024 at 08:15:50PM GMT, Qing Zhao wrote: > > 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) > > Yup; it's good now. Thanks! ;) > > > > 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, > > The number of elements in the array is returned. > The value is a run-time value; not a constant expression. > The behavior is identical to sizeof(a)/sizeof(*a), except that obviously > the operand is only written once, so it's only evaluated once. > > size_t n = arc4random(); > assert(n == __lengthof__(int [n])); > > I think this is covered by > > +The keyword @code{__lengthof__} determines the length of an array operand, > +that is, the number of elements in the array. > > > or a flexible array member? > > A flexible array member is an incomplete type, and so it is a constraint > violation. It results in a compile-time error. > > I think this is covered by > > +The operand must be a complete array type. > > > Should these be clarified in the documentation part? > > I don't know. I think it's already documented. I prefer keeping it > concise, as long as it's not ambiguous. > > > > +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? > > The examples would be rather confusing.
Sorry, I wanted to have removed the line above, after I came up with the example below. :) > > __lengthof__(int [4][n]); // constant expression > __lengthof__(int [n][4]); // run-time value > > I think these would be interesting in the docs. I'll check what would > be the appropriate formatting for these. Thanks! > > > > +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. > > Yes, I agree for a start. But I also don't want to allow any user to > rely on the fact that __lengthof__ rejects pointers to determine that > something is not a pointer, because we reserve the possibility of > extending the operator to work on certain pointers. (I'm not saying > we'll do it; but we reserve the right.) > > Maybe we can just trust that nobody will do that, and complain if we see > anyone using it in that way. > > I think I'll just remove that paragraph. > > Have a lovely night! > Alex > > > > > thanks. > > > > Qing > > -- > <https://www.alejandro-colomar.es/> -- <https://www.alejandro-colomar.es/>
signature.asc
Description: PGP signature
