Torvalds Voices Thoughts On Linux Mitigating Unexpected Arithmetic Overflows/Underflows

[sdack]

when your single contribution to a thread is insults then perhaps it's time for some self reflection? While I personally don't fully agree with coder:s position here, he is not the problem.

You are the one replying to my comment. Nobody asked you to give your opinion to my comment. It makes you a cockroach. They, too, show up where nobody wants them. Go and reflect on that.

[coder]

What everyone advocating for "making things more approachable" (and calling those who oppose them elitists and gatekeeper dweebs) conveniently ignores is that by doing so they are actually advocating for increasing the number of potential issues they will have to handle in the future exponentially as the number of unskilled / untrained people their "inclusion" is enabling keeps growing.

That's one way to look at it, and I'm not saying you're wrong. However, another aspect to consider is that by reducing the "cognitive load" in one aspect of programming, you can raise the bar somewhere else. For instance, C code has a reputation for using poor algorithms and datastructures, in part because standard library support is lacking, but also because the C makes it harder to correctly implement complex algorithms than in many other languages. Even the code optimization enthusiasts among us might appreciate being able to spend more time & energy focusing on the real performance hot spots!

[schmidtbag]

There are multiple ways to solve the same problem, and while some may seem stupid, I'm sure there are instances of people who intentionally take advantage of wrap-arounds. Come to think of it, seems like it'd come in handy for cycle-limited processors, like what you find in microcontrollers, where you want a variable to automatically reset or alternate in value without having to expend any clock cycles to determine what the current value is. Considering the versatility of Linux, every little thing the kernel does to intentionally reduce clock cycles seems like a good thing.
While I think it's good for amateur developers to be aware of their potential mistakes and perhaps take another approach to solve a problem, we ought to be concerned about any professional who cause unintentional wrap-arounds. There's an endless amount of bad development practices out there. We can't nanny all of them. While this particular one is easier to identify than most, the only instances a compiler is going to detect are also simple enough that any skilled developer wouldn't realize it themselves; we shouldn't have unskilled developers submitting to the Linux kernel.

I think what might be nice is for compilers to have "amateur" level verbosity and a "I know what I'm doing" level of verbosity. The former would be for things like wrap-arounds, where maybe it was intentional but not good practice, and the latter would only show warnings where there's no excuse and you really ought to know better.

[coder]

I think what might be nice is for compilers to have "amateur" level verbosity and a "I know what I'm doing" level of verbosity. The former would be for things like wrap-arounds, where maybe it was intentional but not good practice, and the latter would only show warnings where there's no excuse and you really ought to know better.

There are multiple warning levels and collections, which can be used to set the degree of paranoia you want. Beyond that, one can always disable specific warnings that have a high false-positive rate or enable additional ones. I'd probably recommend a novice start out using a higher degree of paranoia and only disable specific warnings after they at least understand what they mean.

• -Wall
• -Wextra
• -Wpedantic (see also -fpermissive)

https://gcc.gnu.org/onlinedocs/gcc-14.1.0/gcc/Warning-Options.html

It should also be noted that GCC's static analyzer isn't exactly the best.

[sdack]

Next do we warn about shift-operations losing high and low bits. Then we warn about and-operations masking bits out. Furthermore, subtractions and divisions can lead to smaller numbers, as well as additions and multiplications can lead to larger numbers, and will need a warning. ... And once we have warned the user of everything, do we warn of using C and C++!

> gcc -Werror hello.c
hello.c:1:1: error: C language detected

[coder]

Next do we warn about shift-operations losing high and low bits.

It's a bad analogy, because you don't use a bit-shift operation unless you want that behavior (same applies to bit masking). With arithmetic overflow/underflow, those are effects that can occur in code where it wasn't intended or expected.

[skeevy420]

What everyone advocating for "making things more approachable" (and calling those who oppose them elitists and gatekeeper dweebs) conveniently ignores is that by doing so they are actually advocating for increasing the number of potential issues they will have to handle in the future exponentially as the number of unskilled / untrained people their "inclusion" is enabling keeps growing.

We shouldn't be striving to lower the requirements to the lowest common denominator -- we should be striving to get people trained to meet those requirements. If some of them can't pass it's not the end of the world -- there are so many other things they can do with their lives.

That's a double-edged sword. A lot of the current Linux kernel programming guidelines and coding styles exist to make things more approachable and human readable. To that extent, the kernel is already being gate-keeped as a person is expected to know 8 spaces, 80 character limits, use the existing macros, etc to non programming things like how to use git and how to use the mailing list. People already have to be trained to meet those requirements and even people who have been trained sometimes have issues doing it correctly (see Bcachefs). Expanding the existing practices to include how math should be handled, security hardening, etc isn't that much of a stretch.

What's the alternative to hardening up how C is used? Rewriting the kernel in a different language? Writing a better C compiler? Those are serious questions, John Shepard.

Wait....my Commander John Sheppard has two P's.



Like O'Neill, with Two L's

[Jakobson]

For me, wrap-around for integer arithmetic in computers is obvious. If there is people developing software that we use who don't know that, they're putting us in a risk. How can someone who works and gets paid for programming a computer don't know the basics of how a computer works?

For instance, wrap-around of signed integers is undefined behavior in C.

[sdack]

It's a bad analogy, because you don't use a bit-shift operation unless you want that behavior (same applies to bit masking). With arithmetic overflow/underflow, those are effects that can occur in code where it wasn't intended or expected.

It is not a bad analogy. It is incompetent people like you who expect a behaviour in hindsight, instead of knowing about it beforehand. If you knew about it beforehand would you expect it to potentially overflow, too, just as you would expect to potentially lose bits in a shift operation or when masking them with an and-operation. Alas, here you are advocating for a warning. You are just a shit programmer, coder.

[ssokolow]

Yes a sum of two positive numbers is never smaller than one of the input values. So the statement is either dead code or an overflow test. Which one should be obvious from what happens inside the branch statement. If it isn't you might need to fix the code, but that isn't really something a static analyser can tell, but it should not warn about overflow where the risk of overflow has been explicitly handled, this is the code an analyser should make you write, not what it should complain about.

Now we're to the "I don't use splint's annotations that are analogous to most of what Rust gives you because retrofitting things into C using verbose comments is so cluttered, distracting, and ugly" part. I fully agree.