Torvalds Voices Thoughts On Linux Mitigating Unexpected Arithmetic Overflows/Underflows

[coder]

Kees is probably accustomed to Google where more cognitive load for somebody else and more line codes are not that big of an issue...but the overall attitude is plain wrong, a sign of these times:

You're stretching quite a bit, to make your indictment. I think you're not really being fair.

I'm seeking some general consensus on taking approach #1 above -> he wants his idea to gain consensus without bothering if it's good or not

He's asking for a consensus, which might be that it's bad.

so that's a universal pain point -> he's already tagged any resistance as lazyness
But I've been beating the "make Linux safer" drum for a long time now -> he's already the good guy

I disagree with both of these characterizations. If he can point to a continual stream of such bugs, that's enough to make the case that these are live issues potentially worth addressing. He clearly believes it's worth addressing, while others might not. Having the discussion, as he sought to do, should either conclude that it's not worth addressing or that it is worth addressing and the rough shape of possible solutions. The outcome would either put the issue to bed or help move it forward. Both seem better than not even having the discussion.

and I hope I can convince folks that we need to actually make a change here -> MY change is better than whatever you orangutans have come up with in the last decades
The status quo isn't good enough-> everybody else is lazy and defending the status quo
and we can do better-> MY idea is clearly better
What are your thoughts, suggestions, alternatives?"-> "NOPE" is not among the options, you can pick your favourite flavour of what I've told you to do

No, he's just advocating for an improvement. He left the door wide open to other solutions.

Geez, what a dumba**.

Wow, I honestly can't remember the last time I saw such an example of motivated reasoning outside of politics. Maybe you should've been a politician instead of tech?

BTW, if you're developing aerospace products, as your name implies, please let me know which ones they are. Given your callous attitude towards improving software quality, I will do my best to stay far away from them!

[smitty3268]

BTW, if you're developing aerospace products, as your name implies, please let me know which ones they are. Given your callous attitude towards improving software quality, I will do my best to stay far away from them!

Probably Boeing

[indepe]

Nobody is saying wraparounds should be banned. Just that there should be a way to detect/handle unintended wraparounds.

Even in your code, I'm sure it's much more the exception than the rule that you actually expect arithmetic overflows/unerflows.

Speak for yourself. The correct way I believe is to use proper tests early on, to rule out overflow later on. This is also more performant in many situations. Especially if it allows moving the test(s) out of a loop.

I frequently use wrap around intentionally in conditions, for example, to get the value of a digit:

unsigned char digit= (unsigned char)ch - (unsigned char)'0';
if (digit <= 9) {
// use it as a digit
}

[josmat]

I kinda disagree with Linus on this one. Wrap-around is expected for anyone with a diploma in electrical engineering or computer science that understands the inner workings of arithmetic operations. It is the opposite of "expected" for pretty much everyone else.

I do not agree. I'm not a professional programmer, I have no diploma in computer science or any kind of engineering (my diploma is actually in music), just an amateur programmer and curious follower of Phoronix and the tech world. 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?

[sdack]

bla bla bla

Those are all your problems. Why would I care for them? You still only expect for someone else to fix your problems and are the incompetent party.

[coder]

The correct way I believe is to use proper tests early on, to rule out overflow later on.

Yes, and that should help the compiler establish that a sanitizer isn't necessary.

I frequently use wrap around intentionally in conditions, for example, to get the value of a digit:

unsigned char digit= (unsigned char)ch - (unsigned char)'0';
if (digit <= 9) {
// use it as a digit
}

Text -> int is code you hopefully write just a couple times, if that, in which case using a "underflow is allowed/expected" operator should be no big deal. How many other such examples do you have?

Also, unless it's performance-critical, I'd use standard library routines for that.

[coder]

Those are all your problems. Why would I care for them? You still only expect for someone else to fix your problems and are the incompetent party.

Okay, I think I've got you figured out.

Given how many aspects of our lives are affected by software written by other people, some of whom will inevitably be less competent than you, the only way your position makes sense to me is that you place more value on the ego-boost you feel, upon experiencing or observing someone else's bug, than whatever harm comes of it.

Well, I think you should care more for your mental health and emotional well-being. Regardless, you shouldn't let it reach the point of imposing your twisted values on others/society.

[sdack]

bla bla bla

You are still only an insecure shit poster on a forum. Why would anyone trust you with their project? A hacker is only someone who is more competent than you are. Of course you should be afraid. You are incompetent.

[toves]

I suspect Linus' response is more from the exasperation of repeatedly seeing the same old suggestions slighly reheated.
Unfortunately unchecked integer over-/under-flows are part of the C language's DNA - as much a feature as a flaw.
Changing the language to deal integer overflows in much the same way as Ada (say) would ultimately mean its not C.
Dealing with array bounds errors would likely require promoting C arrays to a first class type and implementing conformant arrays. The pointer/array equivalence would be lost or at best altered and restricted.
Realistically a new C-with-benefits would require almost all existing C code to be changed or rewritten including most the Linux kernel. Like rewriting the Unix kernel in C++ (Sun tried this last century and failed.)
If you were going to this much trouble you might as well design a modern new kernel/operating system from scratch and code in the safer language of your choice. I might laugh if Oberion were the result.

[kuuchan]

Maybe I am missing something, but if a kernel engineer uses (a + b < a) instead of the shorter (b < 0), isn't that actually in order to include the possibility of wrap around in the condition?

And so it wouldn't be just "fine", but in the absence of more context, most likely a fully correct and intentional use of the feature guaranteed by the language definition?

In Mr. Torvalds' message, the "if (a + b < a)" was preceded by "unsigned int a, b;". As such, (b < 0) will never be true because both a and b are declared non-negative integers, and the expression (a + b < a) in this context is an explicit check for wraparound. HTH!