Am 14. August 2024 01:27:33 MESZ schrieb Alejandro Colomar <a...@kernel.org>: > Hi Xavier, > > On Wed, Aug 14, 2024 at 12:38:53AM GMT, Xavier Del Campo Romero wrote: > > I have been overseeing these last emails - > > Ahhh, good to know; thanks! :) > > > thank you very much for your > > efforts, Alex! > > :-) > > > I did not reply until now because I do not have prior > > experience with gcc internals, so my feedback would probably have not > > been that useful. > > Ok. > > > Those emails from 2020 were in fact discussing two completely different > > proposals at once: > > > > 1. Add _Lengthof + #include <stdlengthof.h> > > 2. Allow static qualifier on compound literals > > Yup. > > > Whereas proposal #2 made it into C23 (kudos to Jens Gustedt!), and as > > you already know by now, proposal #1 received some negative feedback, > > suggesting _Typeof/typeof + some macro magic as a pragmatic workaround > > instead. > > The original author of that negative feedback talked to me in private > a week ago, and said he likes my proposal. We have no negative feedback > anymore. :) > > > Since the proposal did not get much traction and I would had been > > unable to contribute to gcc myself, I just gave up on it. IIRC the > > deadline for new proposals closed soon after, anyway. > > Ok. > > > But I am glad that someone with proper experience took the initiative. > > Fun fact: this is my second non-trivial patch to GCC. I wouldn't say I > had the proper experience with GCC internals when I started this patch > set. But I'm unemployed at the moment, which gives me all the time I > need for learning those. :) > > > I still think the proposal is relevant and has interesting use cases. > > > > > I have only added lengthof for now, not _Lengthof, as suggested by Jens. > > > Depending on feedback, I'll propose the uglified version. > > > > Probably, all of us know why the uglified version is the usual approach > > preferred by the C standard: we do not know how many applications would > > break otherwise. > > Yup. > > > However, we see that this trend is now changing with C23, so probably > > it makes sense to define lengthof directly. > > Yeah, since Jens is in WG14 and he suggested to follow this trend, maybe > we can. If not, it's trivial to change the proposal to use the uglified > name plus a macro. > > Checking <https://codesearch.debian.net>, I see that while several > projects have a lengthof() macro, all of them use it with semantics > compatible with this keyword, so it shouldn't break too much. Maybe > those projects will start receiving diagnostics that they're redefining > a standard keyword, but that's not too bad.
For a WG14 paper you should add these findings to support that choice. Another option would be for WG14 to standardize the then existing implementation with the double underscores. > > As for the parentheses, I personally think lengthof should follow > > similar rules compared to sizeof. > > I think most people agree with this. I still don't, in particular not for standardisation. We have to remember that there are many small C compilers out there. I would not want unnecessary burden on them. So my preferred choice would be a standardisation as a macro, similar to offsetof. gcc (and clang) could then just map that to their builtin, other compilers could use whatever they have at the moment, even just the macros that you have in the paper as a starting point. The rest would be "quality of implementation" What time horizon do you see to add the feature for array parameters? Thanks Jens > > Best regards, > > Have a lovely night! > Alex > -- Jens Gustedt - INRIA & ICube, Strasbourg, France
