Re: [PATCH v5 3/3] c: Add __lengthof__ operator

[David Brown <david.brown@hesbynett.no>]

On 08/08/2024 11:13, Jens Gustedt wrote:
> Hi
> 
> Am 8. August 2024 10:26:14 MESZ schrieb Alejandro Colomar <alx@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
> 
>