Originally posted by F.Ultra
View Post
Announcement
Collapse
No announcement yet.
Torvalds Voices Thoughts On Linux Mitigating Unexpected Arithmetic Overflows/Underflows
Collapse
X
-
Originally posted by CmdrShepard View PostWhat 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.
- Likes 1
Comment
-
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.
Comment
-
Originally posted by schmidtbag View PostI 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.- -Wall
- -Wextra
- -Wpedantic (see also -fpermissive)
It should also be noted that GCC's static analyzer isn't exactly the best.
- Likes 3
Comment
-
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
- Likes 1
Comment
-
Originally posted by sdack View PostNext do we warn about shift-operations losing high and low bits.
- Likes 4
Comment
-
Originally posted by CmdrShepard View Post
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.
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
- Likes 2
Comment
-
Originally posted by josmat View Post
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?
- Likes 1
Comment
-
Originally posted by coder View PostIt'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.Last edited by sdack; 12 May 2024, 01:44 PM.
- Likes 1
Comment
-
Originally posted by carewolf View Post
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.
Comment
Comment