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.
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").
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 ******.
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
--
<https://www.alejandro-colomar.es/>
signature.asc
Description: PGP signature
