4 ms·

> > > > > David Howells did a patch set in 2018 (I believe) to clean up the C code in the kernel so it could be compiled with either C or C++; the patchset wasn

by _zagj 2y ago

> > > > > David Howells did a patch set in 2018 (I believe) to clean up the C code in the kernel so it could be compiled with either C or C++; the patchset wasn't particularly big and mostly mechanical in nature, something that would be impossible with Rust. Even without moving away from the common subset of C and C++ we would immediately gain things like type safe linkage. > > > > > > That is great, but that does not give you memory safety and everyone > > > would still need to learn C++. > > > > The point is that C++ is a superset of C, and we would use a subset of C++ > > that is more "C+"-style. That is, most changes would occur in header files, > > especially early on. Since the kernel uses a lot of inlines and macros, > > the improvements would still affect most of the existing kernel code, > > something you simply can't do with Rust. I have yet to see a compelling argument for allowing a completely new language with a completely different compiler and toolchain into the kernel while continuing to bar C++ entirely, when even just a restricted subset could bring safety- and maintainability-enhancing features today, such as RAII, smart pointers, overloadable functions, namespaces, and templates, and do so using the existing GCC toolchain, which supports even recent vintages of C++ (e.g., C++20) on Linux's targeted platforms. Greg's response: > But for new code / drivers, writing them in rust where these types of bugs just can't happen (or happen much much less) is a win for all of us, why wouldn't we do this? C++ isn't going to give us any of that any decade soon, and the C++ language committee issues seem to be pointing out that everyone better be abandoning that language as soon as possible if they wish to have any codebase that can be maintained for any length of time. side-steps this. Even if Rust is "better," it's much easier to address at least some of C's shortcomings with C++, and it can be done without significantly rewriting existing code, sacrificing platform support, or the incorporation of a new toolchain. For example, as pointed out (and as Greg ignored), the kernel is replete with macros--a poor substitute for genuine generic programming that offers no type safety and the ever-present possibility for unintended side effects due to repeated evaluation of the arguments, e.g.: #define MAX(x, y) (((x) > (y)) ? (x) : (y)) One need only be bitten by this kind of bug once to have it color your perception of C, permanently.

iknowstuff 2y ago
There are clear case studies like the ones by Google (on Android) and Microsoft where introducing rust reduced vulnerabilities by 70%. In the case of android there were zero vulnerabilities discovered in new rust code. Are there similar case studies showing such clear success from adopting C++ over C? The answer appears to be no https://grok.com/share/bGVnYWN5_29baa93d-e774-45ec-898b-19bba077f511 https://grok.com/share/bGVnYWN5_29baa93d-e774-45ec-898b-19bb...
bsder 2y ago
> For example, as pointed out (and as Greg ignored), the kernel is replete with macros--a poor substitute for genuine generic programming that offers no type safety and the ever-present possibility for unintended side effects I never thought I would say that C++ would be an improvement, but I really have to agree with that. Simply adopting the generic programming bits with type safety without even objects, exceptions, smart pointers, etc. would be a huge step forward and a lot less disruptive than a full step towards Rust.
- rincebrain 2y ago
  At this point, I think that would be a misstep. I'm not sure I have an informed enough opinion of the original C++ debate, but I don't think stepping to a C++ subset while also exploring Rust is a net gain on the situation, and has the same kinds of caveats as people who are upset at R4L complain about muddling the waters, while also being almost entirely new and untested if introduced now[1]. [1] - I'm pretty sure some of the closed drivers that do the equivalent of shipping a .o and a shim layer compiled have C++ in them somewhere sometimes, but that's a rounding error in terms of complexity testing compared to the entire tree.
mustache_kimono 2y ago
> Even if Rust is "better," it's much easier to address at least some of C's shortcomings with C++ This simply forgets all the problems C++ has as a kernel language. It's really an "adopt a subset of C++" argument, but even that has its flaws. For instance, no one wants exceptions in the Linux kernel and for good reason, and exceptions are, for better or worse, what C++ provides for error handling.
- _zagj 2y ago
  > It's really an "adopt a subset of C++" argument, but even that has its flaws. For instance, no one wants exceptions in the Linux kernel and for good reason Plenty of C++ codebases don't use exceptions at all, especially in the video game industry. Build with GCC's -fno-exceptions option. > and exceptions are, for better or worse, what C++ provides for error handling. You can use error codes instead; many libraries, especially from Google, do just that. And there are more modern approaches, like std::optional and std::expected: https://en.cppreference.com/w/cpp/utility/optional https://en.cppreference.com/w/cpp/utility/optional https://en.cppreference.com/w/cpp/utility/expected https://en.cppreference.com/w/cpp/utility/expected
  - mustache_kimono 2y ago
    > You can use error codes instead; many libraries, especially from Google, do just that. And there are more modern approaches, like std::optional and std::expected: Even if we are to accept this, we'd be back to an "adopt a subset of C++" argument. You're right in one sense -- these are more modern approaches to errors, which were adopted in 2017 and 2023 respectively (with years for compilers to implement...). But FWIW we should note that these aren't really idiomatic C++, whereas algebraic data types is a baked in, 1.0, feature of Rust. So -- you really don't want to adopt C++. You want to adopt a dialect of C++ (perhaps the very abstract notion of "modern C++"). But your argument is much more like "C++ has lambdas too!" than you may care to admit. Because of course it does. C++ is the kitchen sink. And that's the problem. You may want the smaller language inside of C++ that's dying to get out, but C++'s engineering values are actually "we are the kitchen sink!". TBF Rust's values are sometimes distinct too, but I'm not sure you've really examined just how different C++'s values are from kernel C, and why the kitchen sink might be a problem for the Linux kernel. You say: > RAII, smart pointers, overloadable functions, namespaces, and templates, and do so using the existing GCC toolchain "Modern C++" simply doesn't solve the problem. Google has been very clear Rust + C++ codebases have worked well. But the places where it sees new vulnerabilities are mostly in new memory unsafe (read C++) code. See: https://security.googleblog.com/2024/09/eliminating-memory-safety-vulnerabilities-Android.html https://security.googleblog.com/2024/09/eliminating-memory-s...
TinkersW 2y ago
Ya it rather baffling, it would be a solid improvement, and they can easily ban the parts that don't work for them(exceptions/stl/self indulgent template wankery). On a memory safety scale I'd put C++ about 80% of the way from C to Rust.

by _zagj 2y ago

iknowstuff 2y ago

There are clear case studies like the ones by Google (on Android) and Microsoft where introducing rust reduced vulnerabilities by 70%. In the case of android there were zero vulnerabilities discovered in new rust code. Are there similar case studies showing such clear success from adopting C++ over C? The answer appears to be no https://grok.com/share/bGVnYWN5_29baa93d-e774-45ec-898b-19bba077f511 https://grok.com/share/bGVnYWN5_29baa93d-e774-45ec-898b-19bb...

bsder 2y ago

> For example, as pointed out (and as Greg ignored), the kernel is replete with macros--a poor substitute for genuine generic programming that offers no type safety and the ever-present possibility for unintended side effects I never thought I would say that C++ would be an improvement, but I really have to agree with that. Simply adopting the generic programming bits with type safety without even objects, exceptions, smart pointers, etc. would be a huge step forward and a lot less disruptive than a full step towards Rust.

rincebrain 2y ago
At this point, I think that would be a misstep. I'm not sure I have an informed enough opinion of the original C++ debate, but I don't think stepping to a C++ subset while also exploring Rust is a net gain on the situation, and has the same kinds of caveats as people who are upset at R4L complain about muddling the waters, while also being almost entirely new and untested if introduced now[1]. [1] - I'm pretty sure some of the closed drivers that do the equivalent of shipping a .o and a shim layer compiled have C++ in them somewhere sometimes, but that's a rounding error in terms of complexity testing compared to the entire tree.

mustache_kimono 2y ago

> Even if Rust is "better," it's much easier to address at least some of C's shortcomings with C++ This simply forgets all the problems C++ has as a kernel language. It's really an "adopt a subset of C++" argument, but even that has its flaws. For instance, no one wants exceptions in the Linux kernel and for good reason, and exceptions are, for better or worse, what C++ provides for error handling.

_zagj 2y ago
> It's really an "adopt a subset of C++" argument, but even that has its flaws. For instance, no one wants exceptions in the Linux kernel and for good reason Plenty of C++ codebases don't use exceptions at all, especially in the video game industry. Build with GCC's -fno-exceptions option. > and exceptions are, for better or worse, what C++ provides for error handling. You can use error codes instead; many libraries, especially from Google, do just that. And there are more modern approaches, like std::optional and std::expected: https://en.cppreference.com/w/cpp/utility/optional https://en.cppreference.com/w/cpp/utility/optional https://en.cppreference.com/w/cpp/utility/expected https://en.cppreference.com/w/cpp/utility/expected
- mustache_kimono 2y ago
  > You can use error codes instead; many libraries, especially from Google, do just that. And there are more modern approaches, like std::optional and std::expected: Even if we are to accept this, we'd be back to an "adopt a subset of C++" argument. You're right in one sense -- these are more modern approaches to errors, which were adopted in 2017 and 2023 respectively (with years for compilers to implement...). But FWIW we should note that these aren't really idiomatic C++, whereas algebraic data types is a baked in, 1.0, feature of Rust. So -- you really don't want to adopt C++. You want to adopt a dialect of C++ (perhaps the very abstract notion of "modern C++"). But your argument is much more like "C++ has lambdas too!" than you may care to admit. Because of course it does. C++ is the kitchen sink. And that's the problem. You may want the smaller language inside of C++ that's dying to get out, but C++'s engineering values are actually "we are the kitchen sink!". TBF Rust's values are sometimes distinct too, but I'm not sure you've really examined just how different C++'s values are from kernel C, and why the kitchen sink might be a problem for the Linux kernel. You say: > RAII, smart pointers, overloadable functions, namespaces, and templates, and do so using the existing GCC toolchain "Modern C++" simply doesn't solve the problem. Google has been very clear Rust + C++ codebases have worked well. But the places where it sees new vulnerabilities are mostly in new memory unsafe (read C++) code. See: https://security.googleblog.com/2024/09/eliminating-memory-safety-vulnerabilities-Android.html https://security.googleblog.com/2024/09/eliminating-memory-s...

TinkersW 2y ago

Ya it rather baffling, it would be a solid improvement, and they can easily ban the parts that don't work for them(exceptions/stl/self indulgent template wankery). On a memory safety scale I'd put C++ about 80% of the way from C to Rust.