> 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.
But can doing this in a header be completely sufficient in practice? e.g., the user who passes a pointer rather than an array is in for quite a surprise, or passing a struct, or passing a FAM, etc. If we want to put constraints on the interface, that may be more challenging to do from a header file than from the compiler. offsetof is a cautionary tale in that compilers that want a reasonable QoI basically all implement this as a builtin rather than the header-only version. > 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. True! I'm still thinking on how important rank + extent is vs overall array length. If C had constexpr functions, then I'd almost certainly want array rank and extent to be the building blocks and then lengthof can be a constexpr function looping over rank and summing extents. But we don't have that yet, and "bird hand" vs "bird in bush"... :-D ~Aaron -----Original Message----- From: Jens Gustedt <jens.gust...@inria.fr> Sent: Wednesday, August 14, 2024 8:18 AM To: Ballman, Aaron <aaron.ball...@intel.com>; 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> Subject: RE: v2.1 Draft for a lengthof paper 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_f > w.c?L292-294 > https://sourcegraph.com/github.com/OpenSmalltalk/opensmalltalk-vm/-/bl > ob/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
