On 08/08/2024 11:13, Jens Gustedt wrote:
Hi
Am 8. August 2024 10:26:14 MESZ schrieb Alejandro Colomar <a...@kernel.org>:
Hello Jens,
On Thu, Aug 08, 2024 at 07:35:12AM GMT, Jāāā Gustedt wrote:
Hello Alejandro,
On Thu, 8 Aug 2024 00:44:02 +0200, Alejandro Colomar wrote:
+Its syntax is similar to @code{sizeof}.
For my curiosity, do you also make the same distinction that with
expressions you may omit the parenthesis?
I thought of it. TBH, I haven't tested that thoroughly.
In principle, I have implemented it in the same way as sizeof, yes.
Personally, I would have never allowed sizeof without parentheses, but I
understand there are people who think the parentheses hurt readability,
so I kept it in the same way.
I'm not sure why the parentheses are necessary with type names in
sizeof,
probably because of operator precedence. there would be no rule that tells us
where sizeof ends and we'd switch back from parsing a type to parsing an
expression
I personally have always found it looks odd that the sizeof operator
does not always need parentheses - I suppose that is because it is a
word, rather than punctuation. To me, it looks more like a function or
function-like macro. And I'd view lengthof in the same light. However,
that's just personal opinion, not a rational argument!
but to maintain expectations, I think it would be better to do
the same here.
Just to compare, the recent additions in C23 typeof etc. only have the
parenthesized versions. So there would be precedent. And it really eases
transition
_Alignof (now "alignof") from C11 always needs parentheses too - but it
always applies to a type, not an expression. (I think it should also be
possible to use it with expressions for consistency, but that's another
matter.)
As I see it, there is a good reason to say that a "lengthof" feature
should always have parentheses. With "typeof" (either as the gcc
extension or the C23 feature), you can come a long way to the
functionality of the proposed "lengthof" (or "__lengthof__") using a
macro. This will mean that if someone writes code using the new feature
in gcc, and another person wants to compile the code with older gcc or a
different compiler, they can use a macro (even "#define lengthof(arr)
(sizeof(arr)/sizeof((arr)[0])", which is less safe but works everywhere)
instead. But that is only true of the person writing the original
"lengthof" code has included the parentheses.
I wouldn't be sure that we should continue that distinction from
`sizeof`.
But then, what do we do? Allow lengthof with type names without parens?
Or require parens? I'm not comfortable with that choice.
Also that prefix variant would be difficult to wrap in a
`lengthof` macro (without underscores) as we would probably like to
have it in the end.
Do you mean that I should add _Lengthof? We're adding __lengthof__ to
be a GNU extension with relative freedom from ISO. If I sent a patch
adding _Lengthof, we'd have to send a proposal to ISO at the same time,
and we'd be waiting for ISO to discuss it before I can merge it. And we
couldn't bring prior art to ISO.
With this approach instead, the plan is:
- Merge __lengthof__ in GCC before ISO hears of it (well, there are
already several WG14 members in this discussion, so you have actually
heard of it, but we're free to do more or less what we want).
- Propose _Lengthof to ISO C, with prior art in GCC as __lengthof__,
proposing the same semantics. Also propose a lengthof macro defined
in <stdlength.h>
I don't really see why we should take a detour via _Lengthof, I would hope we
could directly propose lengthof as the standardization
It is traditional for C. It has taken until C23 to get alignof, bool,
etc., as full keywords. I would expect that we would have _Lengthof for
a transitional period while "lengthof" is in "<stdlength.h>" and other
uses of it are deprecated. Changes in C happen slowly if backwards
compatibility is threatened (too slowly for some people, too fast for
others).
- When ISO C accepts _Lengthof and lengthof, map _Lengthof in GCC to
the same internals as __lengthof__, so they are the same thing.
Still, I'm interested in having some feedback from WG14, to prevent
implementing something that will have modifications when merged to
ISO C, so please CC anyone interested from WG14, if you know of any.
I think that more important would be to have clang on board with this.
In any case, thanks for doing this!
Jens
