Hi Aaron, Am 14. August 2024 13:31:19 MESZ schrieb "Ballman, Aaron" <aaron.ball...@intel.com>: > Sorry for top-posting, my work account is stuck on Outlook. :-/ > > > 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. > > +1, it's always good to explain prior art and existing uses as part of the > paper. However, please also point out that C++ has a prior art as well which > is slightly different and very much worth considering: they have one API for > getting the array's rank, and another for getting a specific rank's extent. > This is a general solution that doesn't require the programmer to have deep > knowledge of C's declarator syntax and how it relates to multidimensional > arrays. > > That said, I suspect WG14 would not be keen on standardizing `lengthof` > without an ugly keyword given that there are plenty of other uses of it that > would break: > > https://sourcegraph.com/github.com/illumos/illumos-gate/-/blob/usr/src/cmd/mailx/names.c?L53-55 > https://sourcegraph.com/github.com/Rockbox/rockbox/-/blob/tools/ipod_fw.c?L292-294 > https://sourcegraph.com/github.com/OpenSmalltalk/opensmalltalk-vm/-/blob/src/spur64.stack/validImage.c?L7014-7018 > (and many, many others) > > >> > 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. > > Those compilers already have to handle parsing this for sizeof, so that's not > particularly compelling (even if we wanted to design C for the lowest common > denominator of implementation effort, which I'm not convinced is a good > approach these days). That said, if we went with a rank/extent design, I > think we'd *have* to use parens because the extent interface would take two > operands (the array and the rank you're interested in getting the extent of) > and it would be inconsistent for the rank interface to then not require > parens.
I think that this argument goes too short. E. g. implementation that already have compound expressions (or lambdas ;-) may provide a quality implementation using `static_assert` and `typeof` alone, and don't have to touch their compiler at all. We should not impose an implementation in the language where doing it in a header can be completely sufficient. Plus, implementing as a macro in a header (probably <stddef.h>) makes also a feature test, for those applications that already have something similar. this was basically what we did for `unreachable` and I think it worked out fine. Jens > ~Aaron > > -----Original Message----- > From: Jens Gustedt <jens.gust...@inria.fr> > Sent: Wednesday, August 14, 2024 2:11 AM > To: Alejandro Colomar <a...@kernel.org>; Xavier Del Campo Romero > <xavi....@tutanota.com> > Cc: Gcc Patches <gcc-patches@gcc.gnu.org>; Daniel Plakosh > <dplak...@cert.org>; Martin Uecker <uec...@tugraz.at>; Joseph Myers > <josmy...@redhat.com>; Gabriel Ravier <gabrav...@gmail.com>; Jakub Jelinek > <ja...@redhat.com>; Kees Cook <keesc...@chromium.org>; Qing Zhao > <qing.z...@oracle.com>; David Brown <david.br...@hesbynett.no>; Florian > Weimer <fwei...@redhat.com>; Andreas Schwab <sch...@linux-m68k.org>; Timm > Baeder <tbae...@redhat.com>; A. Jiang <d...@live.cn>; Eugene Zelenko > <eugene.zele...@gmail.com>; Ballman, Aaron <aaron.ball...@intel.com> > Subject: Re: v2.1 Draft for a lengthof paper > > 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 -- Jens Gustedt - INRIA & ICube, Strasbourg, France
