Hacker News Reader

Comment by jeffbee | Hacker News Reader

It will be interesting if this gains traction, while C++ in the kernel never did. Many, many bugs in the Linux kernel would have been prevented with C++ (the entire class of `goto cleanup;` bugs, for example).

View on HN

Check out out slides 20-21 from Linux Security Summit 2019 - there are specific reasons why Linux didn't like C++ that don't apply to Rust. https://ldpreload.com/p/kernel-modules-in-rust-lssna2019.pdf

Basically, we think (and we hope Linus agrees) that Rust has the relevant benefits of C++ without the downsides that have so far kept C++ from being adopted. (It has other great features that C++ doesn't have like compiler-enforced memory safety, too, but I agree with you that RAII is a pretty important and obvious win for the kernel just by itself.)

I fail to see how Rust solves any of the issues in ways that don't apply to C++ (the solution largely seems to be "don't use those features").

Yeah, it's possible to write a disciplined form of C++ that abides by those rules, but I think it's important that the idiomatic form of error handling in Rust is returning Result types instead of unwinding, the standard library doesn't have coercions that allocate, etc. If you write some Rust code following a Rust tutorial, it would probably be kernel-suitable. That's also largelytrue of C but not of C++.

(And Linus noticed one of the big parts where Rust doesn't live up to this - the idiomatic thing for memory allocation failure is to unwind - and that's a solvable problem.)

Result types can be just as idiomatic in C++. The codebase I work in has exceptions disabled and uses absl::Status and absl::StatusOr[1] everywhere.

[1] https://abseil.io/docs/cpp/guides/status

> Result types can be just as idiomatic in C++

If it `can be idiomatic` it means it's not currently idiomatic, and C++ isn't really heading in that direction. There's also a vast suite of C++ programmers out there to who it's very much not idiomatic and downright foreign. So if you're going to fight against how everyone else writes the language, it's best not to use the language.

No, by “can be idiomatic”, I meant “is already idiomatic in many codebases”. To name one prominent example among many, LLVM disables exceptions and requires that errors be returned as a value: https://llvm.org/docs/CodingStandards.html#do-not-use-rtti-o....

Disabling exceptions isn’t “fighting against how everyone else writes the language” - it’s pretty common and well-supported.

Maybe because of this?

> I think that the standard Rust API may simply not be acceptable inside the kernel, if it has similar behavior to the (completely broken) C++ "new" operator.

https://lkml.org/lkml/2021/4/14/1131

I'm not a C++ dev BTW, so this could need more details by someone with background for it.

Eh, that's just Linus continuing to demonstrate how little he knows about C++.

Could you expand? Maybe steel-man what you think his argument would be and your rebuttals?

I can't really do a "steel man" rebuttal because over the years Linus has argued against a language he calls C++, but which is a made up language invented for the purpose of hating it. A straw man, if you will. It is difficult and frankly not worth the trouble to try to rebut an argument that has never risen above the level of "crap", "broken", and "bullshit".

In the particular case of operator new, it's clear from his cumulative statements that Linus is unaware that the programmer provides global ::new, and can make it do whatever the hell he wants it to do. You can also just forbid it and use placement new everywhere.

To be fair, I think most C++ programmers are unaware of replacing global ::new and most don't know about placement new either (from what I've observed). I think lots of people who write library style code do (whether it be for boost, stl, or in their company) but outside of that most C++ devs are not library style devs and are a bit out of the loop on these topics.

Also, I agree with what you said early about RAII solving entire classes of issues that C (and C++ without RAII) has.

Most C programmers are not kernel developers either.

How can you catch allocation failure from ::new? Is it possible without exceptions (which have some other problems in kernel space)?

One can use ::new(std::nothrow), which selects the non-throwing allocation function. Returns nullptr on failure.

They've already responded that their use of "alloc", which is designed more for userspace, is just a temporary thing that they plan to replace before any serious submissions.

Can you give an example?

The alternatives to goto cleanup; have drawbacks too - like being less readable (cleanup code is before the main function body or destructors do things implicitly).

How would having (some of) Linux written in C++ prevent goto bugs?

The goto bugs are often failures to release locks in the error paths, or failure to free some other resource, or sometimes double frees. C++ programs that use RAII locks rarely have these types of issues.

Many casual users never notice these bugs, but if you put a Linux box under enough pressure that some kmalloc fails, it will fall to pieces because the error paths are full of bugs and little-exercised. C has probably the worst error-path control flow of any of the high-level languages.

I am pretty sure that something can go wrong with a bad (partial or missing) rule of 5.

That's why rule of 5 classes are rare in modern C++. But well-written ones help tremendously.

RAII

Reply on news.ycombinator.com