Re: Rust kernel policy

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

On Fri, 21 Feb 2025 at 14:23, Steven Rostedt <rostedt@goodmis.org> wrote:
>
> If I could just get a warning for this stupid mistake:
>
>         size_t ret;
>
>         ret = func();
>         if (ret < 0)
>                 error();

Note that my main beef with the crazy compiler warning is that it
literally triggers for *RANGE CHECKS*.

IOW, it's literally the "if (a < 0 || a > XYZ)" thing that absolutely
MUST NOT WARN. EVER.  If it does, the compiler is broken.

And gcc still warns of it with -Wtype-limits. So we turn that garbage off.

It's worth noting that "-Wtype-limits" is simply a broken concept for
other reasons too. It's not just the "unsigned type cannot be
negative" thing. It has the exact same problems on the other end.

Imagine that you have macros that do sanity testing of their
arguments, including things like checking for overflow conditions or
just checking for invalid values. What a concept - safe programming
practices with proper error handling.

Now imagine that you pass that an argument that comes from - for
example - a "unsigned char". It's the same exact deal. Now the
compiler warns about YOUR CODE BEING CAREFUL.

See why I hate that warning so much? It's fundamentally garbage, and
it's not even about your error condition at all.

Now, what *might* actually be ok is a smarter warning that warns about
actual real and problematic patterns, like your particular example.

Not some garbage crazy stuff that warns about every single type limit
check the compiler sees, but about the fact that you just cast a
signed value to an unsigned type, and then checked for signedness, and
you did *not* do a range check.

Warning for *that* might be a sane compiler warning.

But notice how it's fundamentally different from the current
sh*t-for-brains warning that we explicitly disable because it's broken
garbage.

So don't confuse a broken warning that might trigger for your code
with a good warning that would also trigger for your code.

            Linus