Re: Rust kernel policy

[Linus Torvalds <torvalds@linux-foundation.org>]

On Fri, 21 Feb 2025 at 09:42, Steven Rostedt <rostedt@goodmis.org> wrote:
>
> Because they are arcane and even the gcc documentation recommends avoiding
> them.
>
>  "Note that in general we do not recommend the use of pragmas"
>  https://gcc.gnu.org/onlinedocs/gcc/Pragmas.html

Yeah, #pragma is complete garbage and should never be used. It's a
fundamentally broken feature because it doesn't work AT ALL with a
very core piece of C infrastructure: the pre-processor.

Now, we all hopefully know that the C pre-processor is the _real_
fundamental problem here in how limited it is, but it is what it is.
Given the fact of how weak C pre-processing is, adding a feature like
#pragma was a complete failure.

So gcc - and other compilers - have figured out alternatives to pragma
that actually work within the context of the C pre-processor. The main
one tends to be to use __attribute__(()) to give magical extra
context.

Yes, yes, some kernel code ends up still using pragmas (typically
"#pragma pack()"), but in almost every case I've seen it's because
that code comes from some external project.

We do have a small handful of "disable this compiler warning" uses,
which isn't pretty but when there aren't any alternatives it can be
the best that can be done.

But *nobody* should design anything new around that horrendously broken concept.

> Actually, I would be perfectly fine with fixing all locations that have
> x < 0 where x is unsigned, even if it's in a macro or something. Those
> could be changed to:
>
>        if ((signed)x < 0 || x >= 10) {
>
> If they want to allow unsigned compares.

Absolutely #%^$ing not!

That's literally the whole REASON that broken warning is disabled -
people making the above kinds of incorrect and stupid changes to code
that

 (a) makes the code harder to read

and

 (b) BREAKS THE CODE AND CAUSES BUGS

adding that cast to "(signed)" is literally a bug. It's complete
garbage. It's unbelievable crap. You literally just truncated things
to a 32-bit integer and may have changed the test in fundamental ways.

Sure, if the *other* part of the comparison is comparing against "10"
it happens to be safe. But the keyword here really is "happens". It's
not safe in general.

The other "solution" I've seen to the warning is to remove the "< 0"
check entirely, which is ALSO unbelievable garbage, because the sign
of 'x' may not be at all obvious, and may in fact depend on config
options or target architecture details.

So removing the "< 0" comparison is a literal bug waiting to happen.
And adding a cast is even worse.

The *only* valid model is to say "the warning is fundamentally wrong".
Seriously. Which is why the kernel does that. Because I'm not stupid.

Which is why that warning HAS TO BE DISABLED. The warning literally
causes bugs. It's not a safety net - it's the literal reverse of a
safety net that encourages bad code, or leaving out good checks.

The thing is, a compiler that complains about

         if (x < 0 || x >= 10) {

is simply PURE GARBAGE. That warning does not "help" anything. It's
not a safety thing. It's literally only a "this copmpiler is shit"
thing.

And arguing that us disabling that warning is somehow relevant to
other safety measures is either intellectually dishonest ("I'm making
up shit knowing that it's shit") or a sign of not understanding how
bad that warning is, and how

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.

Educate yourself. The "unsigned smaller than 0" warning is not valid.

             Linus