Am 14. August 2024 14:40:41 MESZ schrieb "Ballman, Aaron" <aaron.ball...@intel.com>: > > 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?
Ithindso. > 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. Yes, with the tools that I listed and the ideas that are already in the paper you can basically do all that, including given valuable feedback in case of failure. I am currently on a summer bike trip, so not able to provide a full reference implantation. But could do so, once I am back. > > 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 Why would you be looping? lengthof only addresses the outer dimension sizeof would need a loop, no ? Generally I would be opposed to imposing a complicated solution for a simple feature Jens > > ~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
