Am 8. August 2024 19:21:23 MESZ schrieb David Brown <david.br...@hesbynett.no>:
>
>
> 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).
The reason is not to use user space identifiers. There __lengthof__ is already
as good as the other weirdo, no reason to add that.
>
> >> - 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
> >
> >
--
Jens Gustedt - INRIA & ICube, Strasbourg, France
