Quote of the week
Both C and C++ has had a lot of development since 1999, and C++ has in fact, in my personal opinion, finally "grown up" to be a better C for the kind of embedded programming that an OS kernel epitomizes. I'm saying that as the author of a very large number of macro and inline assembly hacks in the kernel.— H. Peter Anvin
Posted Apr 5, 2024 0:58 UTC (Fri)
by john.carter (guest, #123615)
[Link] (2 responses)
The amount of work was not mammoth, quite a lot of it I scripted.
The interesting thing is, in the process I found and fixed more bugs than I introduced. (C++ type checking is stricter).
C++ is a completely different language to what it was, they have successfully allowed to evolve and improve, without breaking backward compatibility.
Rewriting the kernel in Rust vs moving the entire kernel codebase to C++?
I now know for certain and from lived experience that the second is possible, easy, and less bug prone.
Adding Rust to kernel vs wholesale moving it to C++? We still have some C code (3rd party libraries) in our system, and each place where you have such an interface creates impedance, possibility for resource leaks and safety issues.
Posted Apr 5, 2024 10:57 UTC (Fri)
by Wol (subscriber, #4433)
[Link] (1 responses)
Afaik the first is not even being considered, so why ask the question?
> The interesting thing is, in the process I found and fixed more bugs than I introduced. (C++ type checking is stricter).
Was the result smaller, and faster? It's not just bugs, but regressions (yes, sometimes the price is worth paying, sometimes it isn't).
> Adding Rust to kernel vs wholesale moving it to C++? We still have some C code (3rd party libraries) in our system, and each place where you have such an interface creates impedance, possibility for resource leaks and safety issues.
And the general consensus from people writing Rust is that - even taking into account debugging said interfaces - it's quicker, safer, and more bug-free to write new code in Rust. I've not worked with Rust - it's on my (far too long) to-do list - but it sounds like they are right.
Cheers,
Posted Apr 7, 2024 5:52 UTC (Sun)
by john.carter (guest, #123615)
[Link]
On pure translation C compiling as C++, no appreciable difference in resulting size or speed, but that's to be expected.
Where code / speed / productivity differences are likely to start are as we do simple things like convert C arrays to std::array making them available range for loops and everything in <algorithm> and removing a _lot_ of one off hand crafted, krufty, "find" or "sort" or .... functions.
Only one regression occurred (I made a mistake). ie. Net bugs count decreased markedly.
Certainly RAII, smart pointers, and off-the-shelf bug free and optimized to within an inch of their lives std library utilities will be good.
Exceptions... undecided yet, a talk at cppcon by Sean Parent made me much more optimistic that they're could be useful in that sort of domain.
std::optional and std::expect are perhaps more familiar to current kernel style.
The best "Quote of the Year" I've read was on secure programming in C++. "An unsafe operation is one where, if the preconditions are violated, undefined behaviour could ensue."
Language tools to aid that is valuable in something like a kernel.
Quote of the week
Quote of the week
Wol
Quote of the week