Linux 5.15 Working Towards Comprehensive Compile-Time & Run-Time Detection Of Buffer Overflows

[TheMightyBuzzard]

You don't bail on C, you just incrementally replace it with Rust or similar.

Sure, for things where you don't give a rodent's posterior about performance or resource usage. Rust has carved out a really useful middle ground for itself but it simply is not capable of replacing C universally.

[oiaohm]

You don't bail on C, you just incrementally replace it with Rust or similar.

There is a question does C have to be replaced. Linux kernel has been progressively extending what C defects can be detected at build time. Sparse with C add a stack more meta data. I remember point that extra sparse stuff out to person who is attempting rust based drivers for Linux that they really need need to make sure they were processing in sparse details on functions. Linux kernel C is not put pure bog standard C.

[pal666]

The real mystery is why there is no update in the language’s standard.

current standard version is c17. c23 is in the works.

It’s not like that compile time checks can’t be added to C.

it's not like they are free

[pal666]

You don't bail on C, you just incrementally replace it with Rust or similar.

language for incremental replacement of c is called c++. rust is language for bankrupting mozilla

[krzyzowiec]

C is not a "high level language". About the only thing lower-level is writing in assembly. And it's not meant to be a high level language. It's meant to be what you use when you really, truly need the number of cycles or memory usage optimized.

C is the first high level language. By that it is meant that you are not coding to an architecture (assembly instructions) but rather to an abstraction that is compiled into architecture specific code. You may have your own definition of what a high level language is, but this one is equally valid.

[krzyzowiec]

Sure, for things where you don't give a rodent's posterior about performance or resource usage. Rust has carved out a really useful middle ground for itself but it simply is not capable of replacing C universally.

Rust can be just as fast or faster.

[Ipkh]

Some people need their perspective widened a little.
C and its derivatives require the developer to manage. The original CPUs and OSs did not do any of this, therefore the coder had to.
Modern languages are nice and all, but that type of automatic memory safety just wasn't available when C was created.
It's really a different environment in computing these days and the advent if Virtual Memory spaces on a per program basis, really are what allows things like Rust and Java to exist. Only truly low level things like OS kernels really need the explicit memory management that C provides. Otherwise, everybody should be using the newer memory safe code paths instead.

[mdedetrich]

Sure, for things where you don't give a rodent's posterior about performance or resource usage. Rust has carved out a really useful middle ground for itself but it simply is not capable of replacing C universally.

Rust may not support as many architectures as C but its definitely not slower than C (either in terms of performance or memory usage).

[darkonix]

Sure, for things where you don't give a rodent's posterior about performance or resource usage. Rust has carved out a really useful middle ground for itself but it simply is not capable of replacing C universally.

I would like to understand what are the reasons behind that affirmation.

[Almindor]

There is a question does C have to be replaced. Linux kernel has been progressively extending what C defects can be detected at build time. Sparse with C add a stack more meta data. I remember point that extra sparse stuff out to person who is attempting rust based drivers for Linux that they really need need to make sure they were processing in sparse details on functions. Linux kernel C is not put pure bog standard C.

Yes, yes it does. C is not fixable. Full stop. Open up a list of CVEs that are language/compile time issues and see for yourself.

You can monkey patch this all you want, add static analyzers and whatnot, anything written in C, C++ or even Go will always be a huge CVE waiting to happen. Rust isn't perfect but it's in a different league when it comes to security constraint enforcement.

That doesn't mean that re-writing the whole kernel is on the table now, but one day it might. Or it might be a separate kernel that keeps ABI compatible who knows. If it doesn't happen like that a new replacement will probably arrive at some point written in Rust or rust-alikes.

Start with the drivers, then individual modules and go from there. Fix the remaining issues along the way (e.g. alloc, panic etc.). Rust has already been more or less chosen for this, and for good reasons.

I'm sure Rust itself will become deprecated one day on this level, replaced by something even better, but that's probably decade or more from now.