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. ~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
