Converting the Kernel to C++(lore.kernel.org) |
Converting the Kernel to C++(lore.kernel.org) |
If you do a lot of meta-programming… why not used a more principled approach like Lex & Yacc? Why not go all the way to design mini-languages and compile them to C? Or design C extensions and compile them to C? You can still have good debugging support with line markers. https://gcc.gnu.org/onlinedocs/cpp/Preprocessor-Output.html
I find it hard not to view stuff like this as a "if Rust gets to be in the kernel, then so should C++!".
Yes, what C++ is supposedly good for – RAII, it actually got a little wrong:
1. Default construction / value initialization: Causes lots of initialization before assignment that is obviously unnecessary. Try allocating a buffer: `std::make_unique<char[]>` surprisingly memsets the buffer.
2. Constructors: No way to fail without exceptions. That buffer example again: Without exceptions, `std::make_unique<char[]>` will actually attempt to memset a nullptr on allocation failure … before your nullptr check (which btw makes the compiler entitled to delete your nullptr check as well).
3. Move is a (burdensome) runtime state that mandates nullability.
4. Destructors: Can't take arguments, forcing objects to contain implicit references to each other.
Rust's affine type system fixes 1-3, but not 4, which only a linear type system could: https://en.wikipedia.org/wiki/Substructural_type_system#The_...
This issue has been mentioned back in 2018: https://lore.kernel.org/lkml/CAOMGZ=HwTjk9JbGNeWHd+Jr3rwOkFO...
I recently migrated a complex cross platform C99 embedded project to C++17. We got the build systems ported in a day and are able to chip away at it piece by piece.
We looked at Rust but the main issue wasn't technical it was the large learning curve for the team. Rust is not as intuitive to C developers are C++ is.
Did you read the entire email? Here's a quote that seems to directly contradict you:
> converting C code to Rust isn't something that can be done piecemeal, whereas with some cleanups the existing C code can be compiled as C++.
As far as I can tell, the author is correct. What is the pattern for converting C to Rust piecemeal?
You can call Rust from C, and C from rust. You can convert it function by function.
No it is not. First example: initialisation of structs
You take a piece and either rewrite it yourself or use a transpiler that produces potentially unsafe Rust code which you then later would want to rewrite into safe Rust code.
I don't think that Linus will allow this since he just commented that he will allow rust in drivers and major subsystems [1].
would have hoped see more answers or see something in here from actual kernel developers.
0: https://github.com/gcc-mirror/gcc/commit/5329b59a2e13dabbe20...
Jeeze. Linus writes like C++ killed his dog or something.
There's plenty of great C++ 'wins' over C that make just doing everyday programming tasks so much easier and simpler for no cost.
You don't need to write so abstract and in the clouds that it becomes impossible to maintain - I certainly don't.
And frankly, you can shoot yourself in the foot just as easily with C, just in different ways.
To be clear: I'm not saying the kernel needs C++, I'm not qualified to write on that specifically. But I am saying C++ is not nearly as bad as he makes it out to be.
made it out to be. That post is over 15 years old at this point, which goes to the very point of the posted article - C++ has (subjective opinion here) improved a lot in that time.
No idea what his current opinion on C++ is. Personally I'd rather there was no C++ or Rust in the Linux kernel. IMHO it would be significantly less of a cognitive burden to convert the entire kernel gradually to C++ than Rust.
But I would necessarily hold a man to opinions he held 15 years ago when the landscape has changed so much in that time. Rust was only born the previous year (2006) and not championed by Mozilla until 2009. Yet here we are and there is support in the official kernel for it anyway, whereas C++? Not so much.
However, hpa seems to be the crazy genius type, so maybe it's all for real.
The thing I'd like to know is, given that the kernel is written in "kernel C", a shared culture about how C should be used together with a hairy mountain of macros, why not make kernel-C a proper language?
It's probably just a number of extensions away. Together with some rules about code generation, it could make for a fairly neat dialect of C that would be much easier to use and understand. It would also pave the way for further experiments with compile time guarantees about soundness of isolated sections of the code.
Because, and we should be honest about this, going any C++-like route would impact the long term quality of submitted code. There should be no technical reason for this, but that does not make it something that should be turned a blind eye on.
gives me some doubts if I should put my time into learning c or not. a lot of the tech I care about uses c++ (i want to work in ANNs) and true the kernels are basically in c but the code is c++.
C may have technical challenges but seemingly personal preferences are much more limited, just like the language. That helps large projects move forward.
To be fair, the latest Github version had the bug already fixed, but it's still a sign the language is basically still in an alpha stage.
As somebody who's been using C++ for eight years, I despise Rust and Zig (and Nim and...) syntax. Don't get me wrong, I like the concept of memory safety, but I think too many languages are going "We have to stand out!" and therefore are creating completely new syntaxes. That may work for you, but frankly, I'm happiest in a language that sticks close to C++ syntax (which is probably one reason I love D so much).
Also, C build errors have nothing to do with C++? What are you getting at there?
(I've heard plenty of complains about Rust syntax, so I'm less so interested in that than what C++ syntax gets right. Unless it's just a familiarity thing...)
&&auto my_closure = [&](int x, int y) { return x + y }
let my_closure = |x: int, y: int| { x + y }
Memory safety is the primary reason people are advocating for Rust in kernel! Given that goal, C++ looks absolutely awful.
Benefits of C++ over Rust: - Far easier and nicer to integrate with an enormous existing C codebase - C semantics are much more similar to C++ than to Rust, so no need to do huge pattern redesigns - No need to suddenly fight a borrow checker and prove lifetimes for a code base that isn't aware of them at all - Interfacing with existing C code will require unsafe interop, which greatly reduces the benefit of Rust's primary selling point - Transitions to C++ code will counterintuitively almost certainly introduce less bugs than rewriting in Rust, because you can do it in a much more piecemeal manner, and only do so in very disciplined way
Why should they rewrite it in Rust?
Also, the interop story with rust is equal or better than C++ in many areas at this point. Aside from tools like bindgen eliminating entire families of footguns, try doing something like registering a member function to a c callback, the way virtually every driver works. The rust equivalent in the extremely immature kernel dev trees are a bit ugly, but already much simpler than the idiomatic C++ equivalents. For additional fun, try and do it safely with a custom allocator or closures in a modern version.
This isn't a bad thing. Failing to compile when there is a memory error is better than leaving it in to later manifest as a mysterious crash or be found by a fuzzer or an attacker. When programming without a borrow checker you have to be the borrow checker yourself. People being their own borrow checker does not scale.
With Rust you have to choose which features to use. Unlike C++, with it's "you pay for what you use" model, Rust's features are arguably still broken, unstable, and under active development. See async rust for example.
> don’t know modern C++ but it seems to have a kind of cult like indoctrination where everything else is wrong and only each persons flavor is correct leading to endless bike shedding.
Indeed you don't know what you're talking about. Adopting a style guide is not the same thing as joining a cult.
C++ has been in active use for around 30 years, and modern C++ for over a decade. People use it just fine, and don't feel the need to evangelize. Other communities sadly still appear to feel a constant need to reassure and convince themselves they didn't made the wrong choice.
An example of the latter: c2rust, which is a work in progress but is very impressive https://github.com/immunant/c2rust
It currently translates into unsafe Rust, but the strategy is to separate the "compile C to unsafe Rust" steps and the "compile unsafe Rust to safe Rust" steps. As I see it, as it makes the overall task simpler, allows for more user freedom, and makes the latter potentially useful even for non-transpiled code. https://immunant.com/blog/2023/03/lifting/
Because it is. And is a statement I agree 100% being a +20-years C developer with a hardwired C parser in my brain: Rust, Zig and some (most?) newer C++ syntax is contorted at minimum (to my eyes).
I wish the only difference were about just new operators, but just the fact that the type has to come after the variable declaration is awful to me (also for returning types in functions declarations). One can tell me 100 reasons why Rust does it this way and they'll probably be all true and right, and you can call me all sort of things but this kind of new syntax puts me off right away.
auto my_closure = [](int x, int y) { return x + y; };
let my_closure = |x: int, y: int| { x + y }
int sum = 0, diff = 0;
auto adder = [&sum](int num) {
sum += num;
// compilation error, author didn't
// mean to capture diff.
diff -= num;
};You should use the right tool for the job.
std::unique_ptr is just a move-only ergonomics type over a bare pointer, it doesn't have extra state. std::shared_ptr is basically no different than Rust's Arc.
Closures specify capture semantics explicitly, so you will always know, and default to copy.
And yes, you can capture local references and leave. Don't do that, or return references to local variables, or lots of other fun stuff.
You use whatever you wish to use. You can also waste time debating whether you should name your variables in camelCase or snake_case. It doesn't matter, and no one will berate you for whatever choice you made.
It's your call. Do you think that having a choice is bad?
One thing I think Rust gets wrong is classes. I absolutely don't understand why you would require a separate `impl` block to provide methods. C++ has a reasonable syntax of providing methods in the class.
This is actually not what you want, because as a rule Safe Rust enforces the use of Rust references which have stricter requirements than C++ references or C/C++/Rust raw pointers, and will otherwise introduce UB. (See the Rustonomicon for a detailed description of those requirements.) A "safe Rust" API is OK when all callers can be proven to satisfy these requirements, otherwise raw pointers are easier even though they must be accessed in an unsafe block.
There are also pitfalls when passing arguments by value to Safe Rust, e.g. a `bool` value MUST be 0 or 1, an `enum` MUST not have an invalid discriminant etc. Breaking any of these requirements when calling Safe Rust from C/C++ makes instant UB a very real possibility.