[CC += David, Florian, Andreas]

On Tue, Aug 06, 2024 at 03:59:11PM GMT, Qing Zhao wrote:
> Hi, Alex,

Hi Qing,

> I noticed that all your 4 versions of the patches and the
> corresponding discussion are all in the same email thread, it’s very
> inconvenient to read. Can you start a new email thread for each of the
> new version of the patch? (i.e, Please not reply to the previous
> version when you have a new version of the patch).

Hmmm; I have the opposite opinion in projects that I maintain.  I prefer
when successive iterations of the same patch set are replies to the same
thread, which allows to easily go back to the previous iterations.

Is there consensus in gcc-patches@ that I should start new threads for
each revision?

I very much prefer to keep using a single thread to keep my sanity, but
I'll do whatever gcc-patches@ maintainers prefer.

> Some more questions and comments below:

Could you please use quoting character?  I find it hard to distinguish
the quoted parts from your own.

> I briefly read the two links you provided as the background of your patch:
> 
> https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2529.pdf
> 
> This is a proposal submitted on 6/4/2020, do you know the current
> status of this proposal?

I CCed the author of that proposal, but he didn't say anything.  The
proposal probably died.

> 
> https://inbox.sourceware.org/gcc/m8s4oqy--...@tutanota.com/T/
> 
> This is some discussion within GCC community on this proposal around
> the same time (the end of May of 2020, before the submission date of
> the proposal).
> 
> From the discussion, I didn’t see a consistent positive opinion on the
> proposal itself.

I've read it.  The feedback was basically that _Lengthof() would be
redundant with ARRAY_SIZE() for those careful enough to use it, and a
dead language feature for the cowboys that don't like seat belts.

However, it didn't take into account the possibility of including array
length information in function parameters declared with array notation,
which is a net improvement for everyone.

I've CCed David (the author of 2020's negative feedback) in case he has
any comments.

From what I've seen in these 4 revisions, feedback is not bad.  I've
also been discussing several array features lately, and it seems like
the way forward.  Hopefully, the general opinion has changed.

BTW, the linux kernel is starting to use macros that magically get the
array length:
<https://lore.kernel.org/all/CAHk-=wgxykmuefpxgsy_vfczdccnyoapcjs8e0bxirfgcer...@mail.gmail.com/>
This is also what shadow utils is doing (done by me).  By having
__lengthof__ work on function parameters, these macros will be usable in
more places.

> So, I am wondering whether you have any new background information
> since then? What’s the major motivation to bring up this proposal
> again this time after 4 years?

When I proposed this a couple of years ago (before knowing about n2539),
there was some positive feedback.  I didn't have the time back then to
implement it, but I have now.  So far, I've only seen positive feedback
about it.

> Rationale:
> 
> -  While compiler extensions already allow implementing ARRAY_SIZE()
>   (<https://stackoverflow.com/a/57537491/6872717>), there's still no
>   way to get the length of a function parameter which uses array
>   notation.
> 
> 
> Is this one of major benefits from this new __lenghth__ operator?

I'd say the main one, yes.  As in, I think C++ might have not been
invented or not have developed their own arrays if we had this
functionality in C back then.

> If so, any rough idea now on how to implement this (i.e, the length of
> a function parameter array).

By implementing the function parameters as actual arrays inside the
compiler instead of just pointers.

<https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2906.pdf>

Martin is working on several array features at the moment.

>  While this first implementation doesn't support those yet
>   (because there are some issues that need to be fixed first), the plan
>   is to add support to those.
> 
> 
> What kind of issues are? What’s the plan to resolve those issues?

n2906.  When n2906 is implemented by Martin, __lengthof__ will be able
to work on function parameters.  He may be able to talk more about it.

> -  The tests seem to work as expected if I compile them manually, and
>   run (the one that should be run) as a normal program.  The one that
>   should not be run also gives the expected diagnostics.
>   Can anyone give advice of why it's not running well under the test
>   suite?
> 
> You might want to check some existing testing cases in GCC’s testsuite
> first to see what kind of directives you are missing in your test
> case. (For example, any testing case in gcc/testsuite/gcc.dg/).

It was some spurious warnings.  Martin helped me with those, and it's
already solved in my working copy.

Have a lovely day!
Alex

-- 
<https://www.alejandro-colomar.es/>

Attachment: signature.asc
Description: PGP signature

Reply via email to