Message-ID: <008cc0939c130ee24fbc71a0407ff82772076668.camel@tugraz.at>
Date: Fri, 21 Feb 2025 20:59:34 +0100
From: Martin Uecker <uecker@...raz.at>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Steven Rostedt <rostedt@...dmis.org>, Dan Carpenter
 <dan.carpenter@...aro.org>, Greg KH <gregkh@...uxfoundation.org>, Boqun
 Feng <boqun.feng@...il.com>, "H. Peter Anvin" <hpa@...or.com>, Miguel Ojeda
 <miguel.ojeda.sandonis@...il.com>, Christoph Hellwig <hch@...radead.org>, 
 rust-for-linux <rust-for-linux@...r.kernel.org>, David Airlie
 <airlied@...il.com>, linux-kernel@...r.kernel.org,  ksummit@...ts.linux.dev
Subject: Re: Rust kernel policy

Am Freitag, dem 21.02.2025 um 11:30 -0800 schrieb Linus Torvalds:
> On Fri, 21 Feb 2025 at 10:31, Martin Uecker <uecker@...raz.at> wrote:
> > 
> > The issue with __attribute__ is that it is always tied to a specific
> > syntactic construct.  Possible it could be changed, but then I do
> > not see a major difference to _Pragma, or?
> 
> Oh, _Pragma() is certainly more usable from a pre-processor
> standpoint, but it's still garbage exactly because it doesn't nest,
> and has no sane scoping rules, and is basically compiler-specific.
> 
> Don't use it.
> 
> It's not any better than __attribute__(()), though. The scoping rules
> for _pragma() are basically completely random, and depends on what you
> do. So it might be file-scope, for example (some pragmas are for
> things like "this is a system header file, don't warn about certain
> things for this"), or it might be random "manual scope" like "pragma
> pack()/unpack()".
> 
> It's still complete garbage.

The standardized version of __attribute__(()) would look like

[[safety(ON)]];
....

[[safety(OFF)]];

which is not bad (and what C++ seems to plan for profiles),
but this also does not nest and is a bit more limited to where
it can be used relative _Pragma.  I don't really see any advantage.

GCC has 

#pragma GCC diagnostic push "-Wxyz"
#pragma GCC diagnostic pop

for nesting. Also not great.

> 
> > > This is non-negotiable. Anybody who thinks that a compiler is valid
> > > warning about
> > > 
> > >          if (x < 0 || x >= 10) {
> > > 
> > > just because 'x' may in some cases be an unsigned entity is not worth
> > > even discussing with.
> > 
> > Do you think the warning is useless in macros, or in general?
> 
> Oh, I want to make it clear: it's not ":useless". It's MUCH MUCH
> WORSE. It's actively wrong, it's dangerous, and it makes people write
> crap code.
> 
> And yes, it's wrong in general. The problems with "x < 0" warning for
> an unsigned 'x' are deep and fundamental, and macros that take various
> types is only one (perhaps more obvious) example of how brokent that
> garbage is.
> 
> The whole fundamental issue is that the signedness of 'x' MAY NOT BE
> OBVIOUS, and that the safe and human-legible way to write robust code
> is to check both limits.
> 
> Why would the signedness of an expression not be obvious outside of macros?
> 
> There's tons of reasons. The trivial one is "the function is large,
> and the variable was declared fifty lines earlier, and you don't see
> the declaration in all the places that use it".
> 
> Remember: source code is for HUMANS. If we weren't human, we'd write
> machine code directly. Humans don't have infinite context. When you
> write trivial examples, the type may be trivially obvious, but REAL
> LIFE IS NOT TRIVIAL.
> 
> And honestly, even if the variable type declaration is RIGHT THERE,
> signedness may be very non-obvious indeed. Signedness can depend on
> 
>  (a) architecture (example: 'char')
> 
>  (b) typedef's (example: too many to even mention)
> 
>  (c) undefined language behavior (example: bitfields)
> 
>  (d) various other random details (example: enum types)
> 
> Dammit, I'm done with this discussion. We are not enabling that
> shit-for-brains warning. If you are a compiler person and think the
> warning is valid, you should take up some other work. Maybe you can
> become a farmer or something useful, instead of spreading your manure
> in technology.
> 
> And if you think warning about an extra "x < 0" check is about
> "security", you are just a joke.

Just in case this was lost somewhere in this discussion: 
it was not me proposing to add this warning. 

Martin

> 
>               Linus

Powered by blists - more mailing lists