Torvalds Voices Thoughts On Linux Mitigating Unexpected Arithmetic Overflows/Underflows

[F.Ultra]

Linus sure got the issue in his crosshairs.
Almost seems as if Linus is saying legacy code works like this so we need to keep it that way.
Programming languages should adopt the best design, not do something a lot of legacy code has been written in.
Look at C's and C++'s adoption of operator precedence.

I'd prefer saturation arithmetic by default and some extra operators and math functions with wraparound integrated without primarily relying on separate helper functions or function overloading.
Some stuff that's compact and easy to mentally work with (low cognitive load).

no that is not at all what he says. What Linus is saying is that for most of the cases where it happens in the kernel, the unsigned overflow is either intentional or not a problem so he doesn't want himself and other being blinded by millions of false positive warnings when compiling.

[F.Ultra]

So the overflow caused an exception and Spark could have found it at compile time. Arianne 5 happened because code was copied from the previous rocket that overrode the protections.

Ada is a better language for the Linux kernel than C or Rust will likely ever be. You can makeup whatever irrelevant arguments that you like.

you completely ignored my first point which was the more important one. And it still stands true today. If Linus changes the kernel to be 100% Ada then the project would instantly die, some one else would fork it before the change and development would continue in the fork. There are probably more D-programmers out there then Ada-programmers and a kernel in D would also be a dead project.

[kevlar700]

you completely ignored my first point which was the more important one. And it still stands true today. If Linus changes the kernel to be 100% Ada then the project would instantly die, some one else would fork it before the change and development would continue in the fork. There are probably more D-programmers out there then Ada-programmers and a kernel in D would also be a dead project.

The usual status quo argument from those already invested. It might take less time to learn Ada than Linux notoriously opaque abstractions. I expect less time than Rust. Of course, Rome wasn't built in a day. The number of Ada programmers can change in a matter of weeks and Adas features mean the bar for kernel code quality would be far easier to reach than with C.

[F.Ultra]

The usual status quo argument from those already invested. It might take less time to learn Ada than Linux notoriously opaque abstractions. I expect less time than Rust. Of course, Rome wasn't built in a day. The number of Ada programmers can change in a matter of weeks and Adas features mean the bar for kernel code quality would be far easier to reach than with C.

you are missing the point completely, Linux took of because there where enough programmers that knew C and also had an itch to create an operating system. Had he released it in Ada then there would have been no one else doing development than Linus himself and without a growing and exploding community the project would have died there and then.

Just look at all the other attempts at writing a OS kernel in Ada, they are all more or less half finished and their community size can be counted on one hand.

Rust might not have as many devs or as large a community as C but they are still orders of magnitude larger than Ada. There have been attempts before of supporting Linux modules in Ada and those went nowhere because as I've already written now several times, there is no large community. For Rust there is, regardless of what you, I or anyone else things about Rust.

And no the number of Ada developers can not change in a matter of weeks. People don't learn C or Rust to code on the Linux kernel, they come to code on the Linux kernel because they have learned C or Rust. Changing Linux to Ada from C would not change devs to suddenly learn Ada, it would just force the devs to stop contributing.

[kevlar700]

Linux took of because there where enough programmers that knew C and also had an itch to create an operating system.

Actually I don't believe that. C compilers were simple enough to be freely available at a time when plenty of AT&Ts C code was available. People were worried by the BSD law suit and LInux became the progressive system.

C is in decline so hopefully a more maintainable code base and being owned by scanning wifi or receiving packets are coming to an end on a system with development at a more care free pace greater than OpenBSD. I don't believe that Rust is the answer personally but it solves the security issues in the main atleast.

[ssokolow]

Not to mention that there's the "Rust is an ML-lineage language in C++ clothing. Given how many people I've seen bad-mouthing Pascal for its syntax over the years, how many people are there who are going to find the prospect of hobby-coding in Ada a turn-off because they don't like Wirth-style syntaxes and aren't being paid to do it?" part.

Rust didn't have to resemble C++, but they made it a conscious decision to make Rust look friendlier to users of C-descended or C-inspired syntaxes.

[Citan]

Sooo this whole discussion is overall above what I can comprehend, but I do notice Linus reverted quite a bit towards his old self.
From reading some comments I understand the OP of that topic needed some technical slap to put him back in place, but there are honestly alternatives ways Linus could have used to express the same kind of definiteness in his position without using expressions bordering ad personam insults... :/

[F.Ultra]

Actually I don't believe that. C compilers were simple enough to be freely available at a time when plenty of AT&Ts C code was available. People were worried by the BSD law suit and LInux became the progressive system.

C is in decline so hopefully a more maintainable code base and being owned by scanning wifi or receiving packets are coming to an end on a system with development at a more care free pace greater than OpenBSD. I don't believe that Rust is the answer personally but it solves the security issues in the main atleast.

it's a completely different thing jumping into a large existing project such as AT&T and being part of something new from scratch. No one learned C to be able to hack on Linux, at the most some people switched from C++ to C.

Sooo this whole discussion is overall above what I can comprehend, but I do notice Linus reverted quite a bit towards his old self.
From reading some comments I understand the OP of that topic needed some technical slap to put him back in place, but there are honestly alternatives ways Linus could have used to express the same kind of definiteness in his position without using expressions bordering ad personam insults... :/

Go read his comments on LKML again, he is not insulting Kees one bit, the only time he rages he does that against a piece of software (which also is not a piece of software that Kees have written). Which can also be seen by the reply by Kees where he basically agrees to most of what Torvalds writes.

[CmdrShepard]

Truly, I say to you that all that Misra achieves is to highlight how problematic C is.

All C programs contain undefined behaviour

Ex: 2-line program in Appendix I of MISRA C:2012

https://youtu.be/CVlkJ-ryeoQ?si=-ScXr-05uuLly7MZ

First, I am not watching a 10 minute video of someone trying to sell me a product and taking his spin as a proof that something (in this case C language) is is broken. If you have a point to make, please do it yourself in writing hopefully more elloquent and with less generalization.

Second, no -- not all C programs contain undefined behavior.

Third, MISRA rules were devised through decades of working on making C code safer. It accomplishes that goal quite commendably provided people follow the rules which, if they can be bothered to use a linter, isn't all that hard to do.

Finally, C is a tool just like Ada or Rust. In right usage scenarios and in the right hands it works wonders. Linux kernel as well as all the embedded stuff all around you (in your car, kitchen, etc) is the proof of that.

I don't mind if you want to waste your time rewriting Linux kernel in Ada. What I do mind is people demanding from C programmers to do it or worse yet demanding that C be changed to be more like Ada or Rust. We need diverse tools -- pliers, hammers, saws, ... not a shelf full of identical precision screwdrivers.

[darkonix]

Second, no -- not all C programs contain undefined behavior.

I would agree with the caveat that it is not always evident to the programmer when C code has undefined behavior.

Third, MISRA rules were devised through decades of working on making C code safer. It accomplishes that goal quite commendably provided people follow the rules which, if they can be bothered to use a linter, isn't all that hard to do.

I think that is the problem. Those rules needed to be created in part because of best practices but also because C compilers can not catch some pitfalls. More recent languages avoid some of those issues.

Finally, C is a tool just like Ada or Rust. In right usage scenarios and in the right hands it works wonders. Linux kernel as well as all the embedded stuff all around you (in your car, kitchen, etc) is the proof of that.

Agreed. However Rust and C target domains overlaps a lot these days (eg Linux Kernel)

I don't mind if you want to waste your time rewriting Linux kernel in Ada. What I do mind is people demanding from C programmers to do it or worse yet demanding that C be changed to be more like Ada or Rust. We need diverse tools -- pliers, hammers, saws, ... not a shelf full of identical precision screwdrivers.

Those are probably C programmers that believe they can get some of the benefits of the other languages "improving" C. Rust programmers prefer just using Rust,
People demanding for migrating big codebases to another language probably don't know what they talking. The Rust in Kernel project for example is doing baby steps and only implementing the infrastructure for modules in Rust, without touching the core.