6 ms·

There are plenty of reasons. As just one of them: C++ is unsafe by default. There's theoretically a safe subset, but there's no precise or consensus definition

There are plenty of reasons. As just one of them: C++ is unsafe by default. There's theoretically a safe subset, but there's no precise or consensus definition of that subset. There's no type-system or language support for helping you stay strictly within that subset (and requiring some kind of marker for if you don't). Often, the most obvious way of doing something is unsafe; for instance, in C++, arr[i] is unsafe, and you have to write arr.get(i) to be safe. (In Rust, arr[i] and arr.get(i) are both safe, and you have to write arr.get_unchecked(i) in an unsafe block if you truly want an unsafe indexing operation.)

tptacek 6y ago
Can you help me understand why locking C++ out of a kernel written almost entirely in C, and which receives huge volumes of new C code every year, wouldn't be an instance of making the perfect the enemy of the somewhat marginally better?
- JoshTriplett 6y ago
  I would question the "somewhat marginally better" part. (Please take all of this with a grain of salt, as I do not write "modern C++" in any professional capacity; its complexity has grown far beyond my knowledge.) I think introducing C++ into the kernel (and getting value from it) would require effort on par with introducing Rust, to provide safer interfaces for things. It would also require a substantial combination of tooling, documentation, and convention, to define a careful subset of C++ for use within the kernel, and to the best of my knowledge that tooling does not already exist. The C++ code would also have to continue interoperating with the existing C code, which means that even if there were a tool to say "warn/error about C++ code that uses one of the unsafe bits that comes from C", the kernel likely couldn't use that without substantial additional integration. And conversely, C++ introduces new potential errors that don't exist in C. The first example that comes to mind: if you use a C++ smart pointer, and do anything that gives you the raw pointer (e.g. &something->field, which is extremely common in kernel code), and put that in a data structure, and then let the smart pointer go out of scope, you now have a use-after-free vulnerability. In C, that would require explicitly freeing the object; in C++, there's no visible code associated with freeing the memory, and nothing in the type system tells you you've done something wrong there. A sufficiently well-trained modern C++ developer presumably would not make such an error very often. But what about a large number of expert-level C developers who are attempting to work with modern C++? Introducing C++ into the kernel would add a substantial amount of complexity, and I'm not at all sure that on balance you'd end up on "marginally better" rather than "worse". I'm not suggesting it couldn't be done, or that it couldn't eventually provide some improvements, but it's not clear to me that it's an obvious win.
  - tptacek 6y ago
    For what it's worth, I think it's a moot point; it's really hard to imagine major new subsystems being written in C++, and not hard to imagine them being written in Rust. But if you're going to have a polyglot kernel, it seems pretty weird to exclude C++ if you're still accepting the majority of your patches in C.
- bluejekyll 6y ago
  I think that’s ultimately the question. Given C++ is not technically safer than C (as the GP points out), is it worth the complexity of adding it to the kernel? I have to say though, most of my hesitation of looking at and trying to contribute to kernel is actually the development model. I think I’ve seen from Linus that it is purposefully obtuse to ensure only people who really want or need to contribute will do so. But now they’re pointing out that they’re having a problem attracting new contributors. Is that due to the language or the development and commit model? Rust would be a huge improvement, but I don’t see how that alone would fix the contribution model.
  - tptacek 6y ago
    I agree that C++ isn't meaningfully safer than C, but the kernel isn't a safe program. If the C kernel was moribund, that'd be one thing, but the opposite thing is true: the standard kernel programming language is C. Meanwhile, it'd be hard (not impossible) to argue that C++ is less safe than C, and there are other considerations besides safety. (C++ in the kernel has been done before; the Click Modular Router, for instance).
    - GoOnThenDoTell 6y ago
      Parts of Darwin too
    - armitron 6y ago
      C is a far simpler language and C++ is at least an order of magnitude more complex (and getting worse). Complexity is inversely correlated with safety. Of course additional considerations (understandability, maintainability) are probably even more important in this case.
    - bluejekyll 6y ago
      > the kernel isn't a safe program But it can be far safer than it is today. I assume you’ve seen Writing an OS in Rust by Philipp Oppermann? The unsafe portions are very small compared to the safe: https://os.phil-opp.com/ https://os.phil-opp.com/ I just don’t see why you’d include C++ at this point when there are far better options that would provide meaningful improvements in safety.
- kdmccormick 6y ago
  Here [1] is one of Linus's more well-known rants about C++. It's in reference to the Git source, but I think most of it applies to his attitude towards using C++ in the kernel as well. [1] http://harmful.cat-v.org/software/c++/linus http://harmful.cat-v.org/software/c++/linus
  - tptacek 6y ago
    Just to be clear, I don't know that anyone in this subthread likes C++. I stopped writing in it in 2003 and I'm glad to be done with it. (I still adore C).
  - ncmncm 6y ago
    Yes, Linus has been wrong on this for a long, long time.
  - JoshTriplett 6y ago
    While I don't think C++ belongs in the Linux kernel, Linus rants and diatribes are not something to laud.
- tialaramex 6y ago
  Having spent some time examining both Linux (written in C) and the Haiku kernel (written in C++) I'm far from clear that C++ is even "marginally better". More complicated is worse right? A kernel like Linux invariably develops its own idiom that I think probably has more influence than any of the C++ syntactic sugar that you'd be allowed to use in that environment. Do you have an example in mind of something you wish people did in Linux that they'd likely do with a restricted C++ dialect but not C?
  - ncmncm 6y ago
    To suggest that C++ is about "syntactic sugar" only demonstrates that you have no comprehension of the topic. C++ is complex because the problems people need it for are complex. C++ enables capturing semantics in libraries that cannot be expressed in any other language. There are reasons why C++ is used, almost exclusively, in the most challenging fields. It will not be easy for you to understand those reasons, because you will need to learn a great deal first. But having learned, if you do, you will understand why it would be foolish to attempt those tasks in a lesser language, and you will regret having used C where it has so limited you.
- fulafel 6y ago
  I think it comes down to your attitude towards complexity, which C++ brings heaps of, and how you rank it among the enemies of software quality.
jariel 6y ago
The 'unsafe' part of C++ is not the reason. C is already unsafe enough. C++ is a Frankenstein of a language, can't really be parsed, so many idioms, nobody agrees on the common subset. If there was a C++ totalitarian who ruled with an 'iron set of idioms, conventions and best practices' maybe 20 years ago and forced the world into his benevolent bidding - then C++ might be useful there, even if 'unsafe'. The memory safety value of Rust is way overblown. That's an important feature but not 'the' feature. Most C++ programs are not dying from memory problems. Rust's value in everything else as well.

tptacek 6y ago

Can you help me understand why locking C++ out of a kernel written almost entirely in C, and which receives huge volumes of new C code every year, wouldn't be an instance of making the perfect the enemy of the somewhat marginally better?

JoshTriplett 6y ago
I would question the "somewhat marginally better" part. (Please take all of this with a grain of salt, as I do not write "modern C++" in any professional capacity; its complexity has grown far beyond my knowledge.) I think introducing C++ into the kernel (and getting value from it) would require effort on par with introducing Rust, to provide safer interfaces for things. It would also require a substantial combination of tooling, documentation, and convention, to define a careful subset of C++ for use within the kernel, and to the best of my knowledge that tooling does not already exist. The C++ code would also have to continue interoperating with the existing C code, which means that even if there were a tool to say "warn/error about C++ code that uses one of the unsafe bits that comes from C", the kernel likely couldn't use that without substantial additional integration. And conversely, C++ introduces new potential errors that don't exist in C. The first example that comes to mind: if you use a C++ smart pointer, and do anything that gives you the raw pointer (e.g. &something->field, which is extremely common in kernel code), and put that in a data structure, and then let the smart pointer go out of scope, you now have a use-after-free vulnerability. In C, that would require explicitly freeing the object; in C++, there's no visible code associated with freeing the memory, and nothing in the type system tells you you've done something wrong there. A sufficiently well-trained modern C++ developer presumably would not make such an error very often. But what about a large number of expert-level C developers who are attempting to work with modern C++? Introducing C++ into the kernel would add a substantial amount of complexity, and I'm not at all sure that on balance you'd end up on "marginally better" rather than "worse". I'm not suggesting it couldn't be done, or that it couldn't eventually provide some improvements, but it's not clear to me that it's an obvious win.
- tptacek 6y ago
  For what it's worth, I think it's a moot point; it's really hard to imagine major new subsystems being written in C++, and not hard to imagine them being written in Rust. But if you're going to have a polyglot kernel, it seems pretty weird to exclude C++ if you're still accepting the majority of your patches in C.
bluejekyll 6y ago
I think that’s ultimately the question. Given C++ is not technically safer than C (as the GP points out), is it worth the complexity of adding it to the kernel? I have to say though, most of my hesitation of looking at and trying to contribute to kernel is actually the development model. I think I’ve seen from Linus that it is purposefully obtuse to ensure only people who really want or need to contribute will do so. But now they’re pointing out that they’re having a problem attracting new contributors. Is that due to the language or the development and commit model? Rust would be a huge improvement, but I don’t see how that alone would fix the contribution model.
- tptacek 6y ago
  I agree that C++ isn't meaningfully safer than C, but the kernel isn't a safe program. If the C kernel was moribund, that'd be one thing, but the opposite thing is true: the standard kernel programming language is C. Meanwhile, it'd be hard (not impossible) to argue that C++ is less safe than C, and there are other considerations besides safety. (C++ in the kernel has been done before; the Click Modular Router, for instance).
  - GoOnThenDoTell 6y ago
    Parts of Darwin too
  - armitron 6y ago
    C is a far simpler language and C++ is at least an order of magnitude more complex (and getting worse). Complexity is inversely correlated with safety. Of course additional considerations (understandability, maintainability) are probably even more important in this case.
  - bluejekyll 6y ago
    > the kernel isn't a safe program But it can be far safer than it is today. I assume you’ve seen Writing an OS in Rust by Philipp Oppermann? The unsafe portions are very small compared to the safe: https://os.phil-opp.com/ https://os.phil-opp.com/ I just don’t see why you’d include C++ at this point when there are far better options that would provide meaningful improvements in safety.
kdmccormick 6y ago
Here [1] is one of Linus's more well-known rants about C++. It's in reference to the Git source, but I think most of it applies to his attitude towards using C++ in the kernel as well. [1] http://harmful.cat-v.org/software/c++/linus http://harmful.cat-v.org/software/c++/linus
- tptacek 6y ago
  Just to be clear, I don't know that anyone in this subthread likes C++. I stopped writing in it in 2003 and I'm glad to be done with it. (I still adore C).
- ncmncm 6y ago
  Yes, Linus has been wrong on this for a long, long time.
- JoshTriplett 6y ago
  While I don't think C++ belongs in the Linux kernel, Linus rants and diatribes are not something to laud.
tialaramex 6y ago
Having spent some time examining both Linux (written in C) and the Haiku kernel (written in C++) I'm far from clear that C++ is even "marginally better". More complicated is worse right? A kernel like Linux invariably develops its own idiom that I think probably has more influence than any of the C++ syntactic sugar that you'd be allowed to use in that environment. Do you have an example in mind of something you wish people did in Linux that they'd likely do with a restricted C++ dialect but not C?
- ncmncm 6y ago
  To suggest that C++ is about "syntactic sugar" only demonstrates that you have no comprehension of the topic. C++ is complex because the problems people need it for are complex. C++ enables capturing semantics in libraries that cannot be expressed in any other language. There are reasons why C++ is used, almost exclusively, in the most challenging fields. It will not be easy for you to understand those reasons, because you will need to learn a great deal first. But having learned, if you do, you will understand why it would be foolish to attempt those tasks in a lesser language, and you will regret having used C where it has so limited you.
fulafel 6y ago
I think it comes down to your attitude towards complexity, which C++ brings heaps of, and how you rank it among the enemies of software quality.

jariel 6y ago

The 'unsafe' part of C++ is not the reason. C is already unsafe enough. C++ is a Frankenstein of a language, can't really be parsed, so many idioms, nobody agrees on the common subset. If there was a C++ totalitarian who ruled with an 'iron set of idioms, conventions and best practices' maybe 20 years ago and forced the world into his benevolent bidding - then C++ might be useful there, even if 'unsafe'. The memory safety value of Rust is way overblown. That's an important feature but not 'the' feature. Most C++ programs are not dying from memory problems. Rust's value in everything else as well.