[PATCH 02/10] compiler.h: add is_const() as a replacement of __is_constexpr()
Martin Uecker
muecker at gwdg.de
Sat Dec 7 00:39:50 PST 2024
Am Freitag, dem 06.12.2024 um 16:26 +0900 schrieb Vincent Mailhol:
> > On Fri. 6 Dec. 2024 at 15:40, Martin Uecker <muecker at gwdg.de> wrote:
> > > > Am Freitag, dem 06.12.2024 um 02:25 +0000 schrieb David Laight:
> > > > > > From: Vincent Mailhol
> > > > > > > > Sent: 05 December 2024 15:31
> > > > > > > >
> > > > > > > > -CC: Martin Uecker <Martin.Uecker at med.uni-goettingen.de>
> > > > > > > > +CC: Martin Uecker <muecker at gwdg.de>
> > > > > > > > (seems that Martin changed his address)
> > > >
> > > > My current one is this: uecker at tugraz.at
> >
> > Ack
> >
> > (...)
> >
> > > > > > > > > > > > + *
> > > > > > > > > > > > + * Glory to Martin Uecker <Martin.Uecker at med.uni-goettingen.de>
> > > > > > > > > >
> > > > > > > > > > IIRC Martin has agreed in the past that the accreditation can
> > > > > > > > > > be removed - especially since it refers to the 'sizeof (void)' trick.
> > > > > > > >
> > > > > > > > I tried to look for such message:
> > > > > > > >
> > > > > > > > https://lore.kernel.org/all/?q=f%3A%22martin+uecker%22+__is_constexpr
> > > > > > > >
> > > > > > > > but couldn't find it. Do you have the link?
> > > > > > > >
> > > > > > > > @Martin, do you agree that I remove the accreditation?
> >
> > So, do you agree to have the accreditation removed in compiler.h?
> > Personally, I do not mind. I am also OK to remove you from the
> > documentation and add you to the CREDITS file if you'd like to.
Sorry, I somehow didn't read this part. Please do whatever you think is
most appropriate (but please update my email to the new above if it
still appears anywhere).
I find it amazing how much time the Linux kernel community spends
revising code to make it work perfectly.
Still, I am wondering whether some of this time and effort should not
be targeted at C compilers and language work to make these macro
hacks unnecessary?
I already found the original motivation for these macros very questionable.
Removing VLAs at the cost having imprecise worst-case bounds strikes
me as fundamentally misguided - at least if security is the motivation.
So maybe there are other good reasons for this, e.g. bad code
for VLAs or risk of jumping the guard page if the attacker can somehow
influence its size (but for this there is -Wvla-larger-than). But even then,
wouldn't it be a more worthwhile and interesting investment of engineering
resources to improving code generation / warnings at the compiler level?
Also the fortification of strlen and co seems something which could be
much better solved with annotations and proper compiler support.
Martin
More information about the linux-arm-kernel
mailing list