Hi Jens, Martin, On Wed, Aug 14, 2024 at 05:44:57PM GMT, Jens Gustedt wrote: > Am 14. August 2024 16:47:32 MESZ schrieb Alejandro Colomar <a...@kernel.org>: > > > > 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 > ;-)
I hadn't thought about it until yesterday after Martin insisted in
preferring lengthof over nelementsof or a contraction of it, and worried
about nelementsof possibly causing ambiguity with multi-dimensional
arrays. But:
VLA is a misnomer.
~~~~~~~~~~~~~~~~~~
First, let's assume length refers to the number of elements, as we all
agree that length should not refer to the size in bytes of an array,
since we already have the term "size" for it, which is consistent with
sizeof.
int vla[3][n];
The array from above is a so-called variable length array, according to
the standard. But it does not have a variable length, according to the
presumed meaning of length. It does indeed have a variable size. The
element of vla is itself an array, which is the one that really has a
variable length (or number of elements, as is the more technical term).
So, if n3187 develops, and really pretends to uniquely and unambiguously
use a term for the number of elements and another one for the size of an
array, it should also rename "variable length array" into "variable size
array".
It is indeed due to this problematic misuse of the colloquial term
length that "lenght" and not "number of elements" is misleading in
multi-dimensional arrays. The standard is very strict in using NoE for
the first dimension of an array (so its true dimension), and not for
the dimensions of arrays that are elements of it.
And now you could say that this is only a problem of multi-dimensional
arrays. It's not. They're just the composition of arrays with elements
of type array. The same problem arises with single dimensional arrays
in complex situations (although, admittedly, this is non-standard):
$ cat vla.c
int
main(void)
{
int n = 5;
struct s {
int v[n];
};
struct s a[3];
return sizeof(a);
}
$ gcc -Wall -Wextra -Wpedantic vla.c
vla.c: In function ‘main’:
vla.c:7:22: warning: a member of a structure or union cannot have a
variably modified type [-Wpedantic]
7 | int v[n];
| ^
$ ./a.out; echo $?
60
a is a VLA even if it is a single-dimension array of known constant
number of elements. Huh? :)
Terminology
~~~~~~~~~~~
Once we've determined that "length" in VLA does refer to the size and
not the number of elements, it's hard to justify a reformation of
terminology that would base on length meaning number of elements.
Indeed, either basing justifications of the origins of length on
strlen(3) or on VLA, we must conclude that "variable length array" must
be renamed to "variable size array". I'm preparing a paper for that.
If eventually that paper would be accepted, I'd prepare a second paper
that would reform every use of size and length with arrays so that size
always refers to the size in bytes, length is completely removed, and
number of elements stands as the only term to refer to the number of
elements.
Have a lovely day!
Alex
> > 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 !
--
<https://www.alejandro-colomar.es/>
signature.asc
Description: PGP signature
