More like: the Linux kernel re-implementation of Rust "print" has a bug that causes it to not adhere to Linux kernel conventions.

I'd expect that now that the bug has been reported, it'd be fixed by just hashing pointer addresses before printing them.

I also expect that "reimplementing X in a different programming language" introduces logic bugs, like the one above, and that those involved have deemed what they get out of it worth the effort of hashing these sort of bugs long term.

From the kernel pov, all of these bugs are safety issues, so the article authors are surprised the unsafe keyword is not required to introduce them, but from Rust's pov, they are just logic bugs, which safe Rust does not protect against. One of the main challenges those working on Rust in the kernel will have is figuring out how to educate other kernel developers about Rust (what it does and does not protect against, setting the right expectations, etc.). I think these articles are a great step in that direction.

> article authors are surprised the unsafe keyword is not required

The often surprising part of raw pointers to system programmers newly dabbling in Rust is that every operation on them is safe, except for deref. You can freely take addresses and do pointer arithmetic on them without having to deal with unsafe, and only have to tell the compiler that you know what you are doing when you either load or store something through them.

That's... simply not true. Pointer arithmetic is not, in general, safe. Example: https://doc.rust-lang.org/std/primitive.pointer.html#method....

Eh... the ptr::add function exists if you want to make extra promises to the compiler to let it optimize better, but if you don't a safe version exists: https://doc.rust-lang.org/std/primitive.pointer.html#method....

> is figuring out how to educate other kernel developers about Rust

Why have one class of logic errors when you can have two?

Why have any? Zero errors is trivially achievable by not writing code.

What if not writing code is an error in and of itself?

If it's worth doing it's already done

It's true, /bin/true.

Why try to improve anything when you could just keep the original implementation around for forever?

The El Camino was supposed to be an improvement. A combination between a car and a truck. It turns out it was not an improvement. It's better to just have a car or a truck. Cutting them in half and then weirdly stitching the two parts together creates a Frankenstein nightmare of bad engineering. Which even the best explanations on the planet can't fix.

As they say, if it ain't broke, don't fix it

The evidence that C is broke is pretty overwhelming at this point.

For varying definitions of "not broke".

Thinking about my uncle, running Windows 97 in his company.

^ If I can try to steel man this, it may be that having two different languages is simply worse than having one, even if the one language is non-optimal. Sure, if you were starting Linux today you wouldn't choose C, and hopefully Linux won't be the last operating system to ever exist, and the next one can use Rust. But Linux uses C, and no one is contemplating a full rewrite, so it's best to stick with C.

I have no idea if this is true, I am very much not a kernel developer.

A higher level summary: A lot of institutional knowledge has been embedded into the C code over the years, sometimes in subtle ways, and a naive port to Rust can introduce security vulnerabilities if some of these subtleties get overlooked.