[CC: s/gcc-patches@/gcc@/] Hi Jens,
On Wed, Aug 14, 2024 at 05:44:57PM GMT, Jens Gustedt wrote:
> > However, strlen(3) came first, and we must respect it.
>
> Sure, string length, a dynamic feature, and array length are two features.
(Except that I've seen --and also written myself-- also string lengths
that are constant expressions).
#define STRLEN(s) (NITEMS(s) - 1)
But that's unimportant. I'm more worried about:
ssize_t
strtcpy(char *restrict dst, const char *restrict src, size_t ndst)
{
bool trunc;
size_t dlen, slen;
if (ndst == 0)
return -1;
slen = strnlen(src, ndst);
trunc = (slen == ndst);
dlen = slen - trunc;
stpcpy(mempcpy(dst, src, dlen), "");
if (trunc)
return -1;
return slen;
}
There should be a distinction between array length and string length.
If we call them both len, the names will be ambiguous.
> But we also have VLA and not VNEA in the standard, So we should respect this
> ;-)
Okay. (Although, when in doubt, I would favour strlen(3) because it's
older, and more stable.) :-)
> > 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 !
Number of elements also makes it consistent with the language used for
referring to the pointer to one after the last element of an array.
I think length and number of elements can coexist. Even you had to use
it in your paper:
... We propose to consequently talk about
- size when talking about size of a type or object in numbers of bytes
- length when talking about the number of elements in an array.
I would say it's fine to use length if there's no ambiguity, but
number of elements in contexts where it could be ambiguous with strings.
That's already an improvement over the status quo (which is always
ambiguous, since an array always has both a length and a size).
Would you mind at least keeping "number of elements" for now, replacing
uses of size, and reconsidering the idea of removing "number of
elements" separately and only after that? That would allow separate
discussion. I'm in favour of the first but not the second.
> "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.
We could call it nelementsof(), or neltsof(). neltsof() is shorter,
so I like it better. (alignof() is already a contraction of
alignmentof(), for prior art in contracting names in operators.)
> > 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"
I guess VLA is already a common enough term that I guess it's blessed.
How do you feel about using it when it's unambiguous, but using number
of elements when it could be ambiguous?
But so is the expression "one past the last element of an array". Both
notations should be able to coexist.
It's not like the problem with size, which is never unambiguous.
Have a lovely day!
Alex
--
<https://www.alejandro-colomar.es/>
signature.asc
Description: PGP signature
