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

[David Brown]

On 08/08/2024 11:13, Jens Gustedt wrote:

Hi

Am 8. August 2024 10:26:14 MESZ schrieb Alejandro Colomar :

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 


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 "" 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

Re: [WWWDocs] Deprecate support for non-thumb ARM devices

[David Brown]

On 25/02/16 14:32, Stefan Ring wrote:
> On Thu, Feb 25, 2016 at 10:20 AM, Richard Earnshaw (lists)
>  wrote:
>> The point is to permit the compiler to use interworking compatible
>> sequences of code when generating ARM code, not to force users to use
>> Thumb code.  The necessary instruction (BX) is available in armv5 and
>> armv5e, even though Thumb is not supported in those architecture variants.
>>
>> It might be worth deprecating v5 and v5e at some point in the future: to
>> the best of my knowledge no v5 class device without Thumb has ever
>> existed - but it's not a decision that needs to be related to this proposal.
> 
> Slightly off topic, but related: What does the "e" stand for? Also,
> what does "l" stand for in armv5tel, which is what I usually get --
> little endian?





The "t" is thumb, "e" means "DSP-like extensions", and I suspect the "l"
is a misprint for "j", meaning the Jazelle (Java) acceleration instructions.

> 
> I have no idea if there is an authoritative source for these host
> specifications and cannot find any. config.guess seems to just rely on
> uname -m.
>