Am 14. August 2024 16:47:32 MESZ schrieb Alejandro Colomar <[email protected]>:
> On Wed, Aug 14, 2024 at 03:50:21PM GMT, Jens Gustedt wrote:
> > > > >
> > > > > That said, I suspect WG14 would not be keen on standardizing
> > > > > `lengthof` without an ugly keyword given that there are plenty of
> > > > > other uses of it that would break:
> > > > >
> > > > > https://sourcegraph.com/github.com/illumos/illumos-gate/-/blob/usr/src/cmd/mailx/names.c?L53-55
> > > > > https://sourcegraph.com/github.com/Rockbox/rockbox/-/blob/tools/ipod_fw.c?L292-294
> > > > > https://sourcegraph.com/github.com/OpenSmalltalk/opensmalltalk-vm/-/blob/src/spur64.stack/validImage.c?L7014-7018
> > > > > (and many, many others)
> > >
> > > What regex did you use for searching?
> > >
> > > I was thinking of renaming the proposal to elementsof(), to avoid
> > > confusion between length of an array and length of a string. Would you
> > > mind checking if elementsof() is ok?
> >
> > No, not for me. I really want as to go consistently to talk about
> > array length for this. Consistent terminology is important.
>
> I understand your desire for consistency. I think your paper is a net
> improvement over the status quo (which is a mix of length, size, and
> number of elements). After your proposal, there will be only length and
> number of elements. That's great.
>
> However, strlen(3) came first, and we must respect it.
Sure, string length, a dynamic feature, and array length are two features.
But we also have VLA and not VNEA in the standard, So we should respect this ;-)
> Since you haven't proposed eliminating "number of elements" from the
> standard, and it would still be used alongside length, I think
> elementsof() would be consistent with your view (consistent with "number
> of elements").
didn't we ? Then this is actually a good idea to do so, thanks for the idea !
"elements of" is a stretch, linguistically, because you don't mean the
elements themselves, you are referring to their number. "elementsof" for
me would refer to a list of these elements.
> Alternatively, you could use a new term, for example extent, for
> referring to the number of elements of an array. That would be more
> respectful to strlen(3), keeping a strong distinction between string
> length and array ******.
Only that this separation doesn't exist, even now, as said, it is called
"variable length array"
> Or how about always referring to it as "number of elements"? It's
> longer to type, but would be the most consistent approach.
>
> Also, elementsof() is free to use, while lengthof() has a several
> existing incompatible cases (as Aaron has shown), so we can't use that
> name so freely.
>
> > > I have concerns about a libc (or a predefined macro) implementation:
> > > the sizeof division causes double evaluation with any VLAs, while my
> > > implementation for GCC has less cases of evaluation, and when it needs
> > > to evaluate, it only does it once. It would be hard to find a good
> > > wording that would allow an implementation to implement this as a macro.
> >
> > No, we should not allow double evaluation.
> >
> > putting this in a `({ })`
>
> I would love to see a proposal for adding this GNU extension to ISO C.
> Did nobody do it yet? I could try to, if I find some time. (But I'll
> take a longish time for that; if anyone else does it, it would be
> great.)
>
> > and doing a `typedef typeof(X) _my_type;` with the macro parameter `X` at
> > the beginning completely avoids double evaluation. So quality implantations
> > are
> > possible, but perhaps differently and with other builtins than we are
> > imagining. Don't impose the view of one particular implementation onto
> > others.
>
> Ahhh, good. I haven't thought of that possibility. Sure, that makes
> sense now. It gives more strength to your proposal of allowing libc
> implementations, and thus require parens in the standard.
>
> > Somewhere was brought in an argument with `offsetof`.
> > This is exactly what we need. Implementations being able to start
> > with a simple solution (as everybody did in the beginning of
> > `offsetof`), and improve that implementation at their pace when they
> > are ready for it.
>
> Agree.
>
> > > > this was basically what we did for `unreachable` and I think it worked
> > > > out fine.
> >
> > I still think that the different options that we had there can be used
> > to ask the right questions for WG14.
>
> I'm looking at it. I've already taken some parts of it. :)
>
> Cheers,
> Alex
>
--
Jens Gustedt - INRIA & ICube, Strasbourg, France
