[jtorsella]

Oh wow, someone should alert the Linux kernel maintainers. Do you want to tell them that it’s impossible to write correct C code? And the rust compiler team, too. After all, if nobody can write safe assembly then whatever they’re doing is either unsafe or magically gets the computer to understand rust directly. Or are they relying on LLVM for their code generation? I forget what language that’s written in, but nothing “unsafe” happens there surely.

All code is machine code at bottom. Including the code that maintains abstractions convincing enough for you to think the “memory-safety” of rust or any other language is a static and guaranteed thing and not something that needs “unsafe” scaffolding to support it.

[preseinger]

i'm sure the linux kernel maintainers already know that it's impossible for them to write correct C code, no need to tell them

[tialaramex]

The Rust compiler developers are well aware that it's not possible to write 100% correct code at scale, not least for their dependencies, LLVM provides Rust with ICE (cases where your program crashes the compiler) and with soundness holes where the LLVM behaviour is definitely wrong but it's arguably exactly why and so until LLVM developers decide why it's wrong and fix it, Rust has to either work around that or accept sub-par results.

Much of the Rust compiler is written in Rust and so has fewer problems.

[pjmlp]

Indeed, https://www.cvedetails.com/vulnerability-list/vendor_id-33/p...

[jtorsella]

If the existence of C cves in the kernel proves that it is impossible to write correct C, then by the same token any cves in any rust code prove the same thing about rust. This is such a lazy way of arguing. Say something about why the tradeoffs favor a more restrictive and less performant language or don’t, but don’t dismiss the work of many thousands of C developers that runs most enterprise systems with a knowing wave of the hand - it’s not serious.

[pjmlp]

So you want something more serious,

https://msrc.microsoft.com/blog/2019/07/a-proactive-approach...

https://security.apple.com/blog/towards-the-next-generation-...

https://www.chromium.org/Home/chromium-security/memory-safet...

https://security.googleblog.com/2022/08/making-linux-kernel-...

Σ (memory corruption) + Σ (logic errors) ≥ Σ (logic errors)

So by reducing in 70% the costs of fixing the errors caused by those thousands of experts, as validated by the above reports, there is already a considerable reduction in software development expenses.

Lets see how serious those developers get to be around security issues, when liability finally takes off.

[jtorsella]

I appreciate that you are making an argument and will respond when I get a chance later in the day and after I read a few of the links - I’m familiar with like half of them.

[preseinger]

it is not anyone's claim that the existence of C cves means it is impossible to write correct C

the point that is being made (obliquely) is that manual memory management is not possible for human beings to do effectively at scale

at scale means across a broad demographic of programmers, working on a broad set of programs

if you wanted performant and portable then C was all you had for a long time, and there is a lot of good software written in C, but that does not mean that it is a good tool in perpetuity

strcpy and pointer arithmetic are basically not possible to get right

we need to move beyond this very low level of abstraction