4 ms·

> 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 lan

> 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...
  - IcyWindows 2y ago
    Isn't "Rust without panics" a subset of Rust?
    - mustache_kimono 2y ago
      > Isn't "Rust without panics" a subset of Rust? I'm not sure there is much in your formulation. It would seem to me to be a matter of program design, and programmer discretion, rather than a "subset of the language". Re: C++, we are saying "Don't use at least these dozen features, because they don't work well at many cooks scale, and/or they combine in ways which are non-orthogonal. We don't want you to use them because they complect[0] the code." Re: no panic Rust, we are saying "Don't call panic!(), because obviously you want a different program behavior in this context." These are different things. [0]: https://www.youtube.com/watch?v=SxdOUGdseq4 https://www.youtube.com/watch?v=SxdOUGdseq4
- 112233 2y ago
  And -fno-exceptions, while being de-facto standard e.g. in gamedev, still is not standard C++ (just look how much STL stuff in n4950.pdf is specified as throwing, most of those required for freestanding too (16.4.2.5)). And you cannot just roll your own library in a standard compliant way, because it contains secret compiler juice for, e.g. initializer_list or coroutines. And once you use your own language dialect (with -fno-exceptions), who is to stop you from "customizing" other stuff, too?
  - _zagj 2y ago
    > And -fno-exceptions, while being de-facto standard e.g. in gamedev, still is not standard C++ So? The Linux kernel has freely relied on GCC-specific features for decades, effectively being written in "GCC C," with it only becoming buildable with Clang/LLVM in the last two years. >(just look how much STL stuff No one said you have to use the STL. Game devs often avoid it or use a substitute (like EASTL) more suitable for real-time environments.
    - 112233 2y ago
      > So? The Linux kernel has freely relied on GCC-specific features for decades That is unironically admirable. Either they have their man on GCC team, or have been fantastically lucky. In the same decades there have been numerous GCC extensions and quirks that have been removed [edit: from the gcc c++ compiler] once new standard proclaims them non-conformant. So, which C++ dialect would provide tangible benefits to a freestanding self-modifying code that is Linux kernel, without bringing enough problems to outweight it all completely? RAII and templates are nice, but it comes at the cost of making code multiple orders of magnitude harder to reason about. You cannot "simply" add C++ to sparse/coccinelle. And unlike rust, c++ compiler does not really care about memory bugs. I mean, the c++ committee introduced "start_lifetime_as", effectively declaring all existing low-level c++ programs invalid, and made lambdas that by design can capture references to local variables then be passed around. Why would you set yourself up to have rug pulled out on the next C++ revision if you are not forced to? C++ is a disability that can be accomodated, not something you do to yourself on purpose.
EasyMark 2y ago
isn't that why you pick a particular subset, and exclude the rest of the language? It should be pretty easy to avoid using try/catch, especially in the kernel. A subset of C probably doesn't make much sense but for c++ which absolutely gigantic, it shouldn't be hard. Getting programmers to adhere to it could be handled 99% of the time with a linter, the other 1% can be code by reviewers.
- mustache_kimono 2y ago
  > isn't that why you pick a particular subset, and exclude the rest of the language? If the entire natural inclination of the language is to use exceptions, and you don't, beginning with C++17 and C++23, I'm less sure that is the just right fit some think it is. > Getting programmers to adhere to it could be handled 99% of the time with a linter, the other 1% can be code by reviewers. What is the tradeoff being offered? Additional memory safety guarantees, but less good than Rust, for a voluminous style guide to make certain you use the new language correctly?
  - _zagj 2y ago
    > If the entire natural inclination of the language is to use exceptions, and you don't, beginning with C++17 and C++23 I've personally written libraries targeting C++20 that don't use exceptions. Again, error codes, and now std::optional and std::expected, are reasonable alternatives. > What is the tradeoff being offered? Additional memory safety guarantees, but less good than Rust, for It's not letting the perfect be the enemy of the good. It's not having to rewrite existing code significantly, or adopt a new toolchain, or sacrifice support for any platform Linux currently supports with a GCC backend.

_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...
- IcyWindows 2y ago
  Isn't "Rust without panics" a subset of Rust?
  - mustache_kimono 2y ago
    > Isn't "Rust without panics" a subset of Rust? I'm not sure there is much in your formulation. It would seem to me to be a matter of program design, and programmer discretion, rather than a "subset of the language". Re: C++, we are saying "Don't use at least these dozen features, because they don't work well at many cooks scale, and/or they combine in ways which are non-orthogonal. We don't want you to use them because they complect[0] the code." Re: no panic Rust, we are saying "Don't call panic!(), because obviously you want a different program behavior in this context." These are different things. [0]: https://www.youtube.com/watch?v=SxdOUGdseq4 https://www.youtube.com/watch?v=SxdOUGdseq4
112233 2y ago
And -fno-exceptions, while being de-facto standard e.g. in gamedev, still is not standard C++ (just look how much STL stuff in n4950.pdf is specified as throwing, most of those required for freestanding too (16.4.2.5)). And you cannot just roll your own library in a standard compliant way, because it contains secret compiler juice for, e.g. initializer_list or coroutines. And once you use your own language dialect (with -fno-exceptions), who is to stop you from "customizing" other stuff, too?
- _zagj 2y ago
  > And -fno-exceptions, while being de-facto standard e.g. in gamedev, still is not standard C++ So? The Linux kernel has freely relied on GCC-specific features for decades, effectively being written in "GCC C," with it only becoming buildable with Clang/LLVM in the last two years. >(just look how much STL stuff No one said you have to use the STL. Game devs often avoid it or use a substitute (like EASTL) more suitable for real-time environments.
  - 112233 2y ago
    > So? The Linux kernel has freely relied on GCC-specific features for decades That is unironically admirable. Either they have their man on GCC team, or have been fantastically lucky. In the same decades there have been numerous GCC extensions and quirks that have been removed [edit: from the gcc c++ compiler] once new standard proclaims them non-conformant. So, which C++ dialect would provide tangible benefits to a freestanding self-modifying code that is Linux kernel, without bringing enough problems to outweight it all completely? RAII and templates are nice, but it comes at the cost of making code multiple orders of magnitude harder to reason about. You cannot "simply" add C++ to sparse/coccinelle. And unlike rust, c++ compiler does not really care about memory bugs. I mean, the c++ committee introduced "start_lifetime_as", effectively declaring all existing low-level c++ programs invalid, and made lambdas that by design can capture references to local variables then be passed around. Why would you set yourself up to have rug pulled out on the next C++ revision if you are not forced to? C++ is a disability that can be accomodated, not something you do to yourself on purpose.

EasyMark 2y ago

isn't that why you pick a particular subset, and exclude the rest of the language? It should be pretty easy to avoid using try/catch, especially in the kernel. A subset of C probably doesn't make much sense but for c++ which absolutely gigantic, it shouldn't be hard. Getting programmers to adhere to it could be handled 99% of the time with a linter, the other 1% can be code by reviewers.

mustache_kimono 2y ago
> isn't that why you pick a particular subset, and exclude the rest of the language? If the entire natural inclination of the language is to use exceptions, and you don't, beginning with C++17 and C++23, I'm less sure that is the just right fit some think it is. > Getting programmers to adhere to it could be handled 99% of the time with a linter, the other 1% can be code by reviewers. What is the tradeoff being offered? Additional memory safety guarantees, but less good than Rust, for a voluminous style guide to make certain you use the new language correctly?
- _zagj 2y ago
  > If the entire natural inclination of the language is to use exceptions, and you don't, beginning with C++17 and C++23 I've personally written libraries targeting C++20 that don't use exceptions. Again, error codes, and now std::optional and std::expected, are reasonable alternatives. > What is the tradeoff being offered? Additional memory safety guarantees, but less good than Rust, for It's not letting the perfect be the enemy of the good. It's not having to rewrite existing code significantly, or adopt a new toolchain, or sacrifice support for any platform Linux currently supports with a GCC backend.