Am Mittwoch, dem 14.08.2024 um 12:40 +0000 schrieb Ballman, Aaron:
> > 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
An operator that returns an array with all dimensions of a multi-dimensional
array would make a a lot of sense to me.
double array[4][3][2];
// array_dims(array) = (constexpr size_t[3]){ 4, 3, 2 }
int dim1 = (array_dims(array))[0]
int dim2 = (array_dims(array))[1]
int dim3 = (array_dims(array))[2]
You can then implement lengthof in terms of this operator:
#define lengthof(x) (array_dims(array)[0])
and you can obtain the rank by applying lengthof to the array:
#define rank(x) lengthof(array_dims(x))
If the array is constexpr for regular arrays and array
indexing returns a constant again for constexpr arrays, this
would all work out.
Martin
>
> ~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
--
Univ.-Prof. Dr. rer. nat. Martin Uecker
Graz University of Technology
Institute of Biomedical Imaging
