4 ms·

Overall interesting read. I'm rooting for Sean. If he has faith that C++ is not too far gone to be saved...perhaps I can, too. > Explain the infeasibility of m

Overall interesting read. I'm rooting for Sean. If he has faith that C++ is not too far gone to be saved...perhaps I can, too. > Explain the infeasibility of making legacy lvalue- and rvalue-references memory safe. > Relocation must replace move semantics He advocates for adding lots of things to the language, but that point is a massive change to the language IMO. I definitely think move semantics are awful; as is the hierarchy of rvalues (xvalues and glvalues) is nuts, but at this point can they be removed from the language? Or do I misinterpret the point? Perhaps this is different between unsafe blocks (vs default safe blocks)?

pjmlp 2y ago
If you check the flames on Reddit, not sure if he will keep at it, the WG21 feedback has been pretty disapointing, hence this paper, as kind of response to those replies. Most folks at WG21 think profiles will magically solve the problem, even though many of the ideas are only available on paper, not a random C++ compiler. The biggest issue is that while a language like Ada also has profiles, the safety culture is much different, and they are part of the ecosystem since Ada83, not something that was added later.
- blub 2y ago
  Author’s paper also doesn’t solve the problem, because I wager most C++ programmers wouldn’t touch this rustified C++, which manages to look even worse than the already not light on the eyes original.
  - pjmlp 2y ago
    Probably, but then they will need to decide how much they feel like if C++ joins the computing equivalent of hazardous goods, where products written on it only have clearance for specific use cases. See "Product Security Bad Practices" from CISA and FBI, published last week. https://www.cisa.gov/resources-tools/resources/product-security-bad-practices https://www.cisa.gov/resources-tools/resources/product-secur... => "Software manufacturers should build products in a manner that systematically prevents the introduction of memory safety vulnerabilities, such as by using a memory safe language or hardware capabilities that prevent memory safety vulnerabilities. Additionally, software manufacturers should publish a memory safety roadmap by January 1, 2026."
    - rfoo 2y ago
      > such as by using a memory safe language or hardware capabilities that prevent memory safety vulnerabilities Heh, now I do believe that my partially-memory-corruption-based side job may be in danger. If it was just "by using a memory safe language" I do not care, but if they want to boost hardware assisted mitigations (better and ubiquitous memory tagging etc) it's going to have significant impact.
      - steveklabnik 2y ago
        They are advocating for a holistic approach for safety. But of course, when talking about a specific part of that, they’ll talk about the specifics. With regards to programming languages, memory safety is the next big thing to tackle.
        pjmlp 2y ago
        Ironically some Turing Awards could already see this coming in 1980, but it was needed some money to be tied to CVE's, to make this actually matter. "A consequence of this principle is that every occurrence of every subscript of every subscripted variable was on every occasion checked at run time against both the upper and the lower declared bounds of the array. Many years later we asked our customers whether they wished us to provide an option to switch off these checks in the interests of efficiency on production runs. Unanimously, they urged us not to--they already knew how frequently subscript errors occur on production runs where failure to detect them could be disastrous. I note with fear and horror that even in 1980 language designers and users have not learned this lesson. In any respectable branch of engineering, failure to observe such elementary precautions would have long been against the law." -- C.A.R Hoare's "The 1980 ACM Turing Award Lecture" It is only taking a couple of decades to get there. By the way I know you already are aware of this, more for those that don't.
        gpderetta 2y ago
        > It is only taking a couple of decades to get there. I don't know how to break it to you, but the Eighties were 40 years ago :( In any case I was wondering if Hoare, in addition to bound checkings, felt as strongly about the so called temporal safety, but his words are unambiguous: he is not just rejecting any form of Undefined Behaviour, he wants anything that passes static checking to have useful valid semantics, reminiscent of the "well typed programs can't go wrong" maxim.
- jeffreygoesto 2y ago
  It is a gargantuan endeavour tbh. I am writing safety C++ code for a living and still am undecided if it is a good idea to continue to do so. Safety benefits a lot from understandability and that is undoubtedly better with simple code and a simple(r) language. Trying to keep the legacy code alive through compatibility introduces more than two languages in one, as all the combinations must be understood as well. Wrapping legacy code into bigger "unsafe" blocks and guarding the perimeter of that block is not a bad idea, it creates less mix to reason about. Would allowing only safe references in safety code really hinder adoption?
- AlotOfReading 2y ago
  The folks talking about profiles and the folks talking about rust-like semantics are speaking past each other. They're not solutions to the same problem. Profiles is essentially "let's formalize the 80% cases of easy static analysis rules and deal with the hard stuff later". It doesn't get you memory safety in the sense of rust where it's safe if it compiles (modulo unsafe).

pjmlp 2y ago

If you check the flames on Reddit, not sure if he will keep at it, the WG21 feedback has been pretty disapointing, hence this paper, as kind of response to those replies. Most folks at WG21 think profiles will magically solve the problem, even though many of the ideas are only available on paper, not a random C++ compiler. The biggest issue is that while a language like Ada also has profiles, the safety culture is much different, and they are part of the ecosystem since Ada83, not something that was added later.

blub 2y ago
Author’s paper also doesn’t solve the problem, because I wager most C++ programmers wouldn’t touch this rustified C++, which manages to look even worse than the already not light on the eyes original.
- pjmlp 2y ago
  Probably, but then they will need to decide how much they feel like if C++ joins the computing equivalent of hazardous goods, where products written on it only have clearance for specific use cases. See "Product Security Bad Practices" from CISA and FBI, published last week. https://www.cisa.gov/resources-tools/resources/product-security-bad-practices https://www.cisa.gov/resources-tools/resources/product-secur... => "Software manufacturers should build products in a manner that systematically prevents the introduction of memory safety vulnerabilities, such as by using a memory safe language or hardware capabilities that prevent memory safety vulnerabilities. Additionally, software manufacturers should publish a memory safety roadmap by January 1, 2026."
  - rfoo 2y ago
    > such as by using a memory safe language or hardware capabilities that prevent memory safety vulnerabilities Heh, now I do believe that my partially-memory-corruption-based side job may be in danger. If it was just "by using a memory safe language" I do not care, but if they want to boost hardware assisted mitigations (better and ubiquitous memory tagging etc) it's going to have significant impact.
    - steveklabnik 2y ago
      They are advocating for a holistic approach for safety. But of course, when talking about a specific part of that, they’ll talk about the specifics. With regards to programming languages, memory safety is the next big thing to tackle.
      - pjmlp 2y ago
        Ironically some Turing Awards could already see this coming in 1980, but it was needed some money to be tied to CVE's, to make this actually matter. "A consequence of this principle is that every occurrence of every subscript of every subscripted variable was on every occasion checked at run time against both the upper and the lower declared bounds of the array. Many years later we asked our customers whether they wished us to provide an option to switch off these checks in the interests of efficiency on production runs. Unanimously, they urged us not to--they already knew how frequently subscript errors occur on production runs where failure to detect them could be disastrous. I note with fear and horror that even in 1980 language designers and users have not learned this lesson. In any respectable branch of engineering, failure to observe such elementary precautions would have long been against the law." -- C.A.R Hoare's "The 1980 ACM Turing Award Lecture" It is only taking a couple of decades to get there. By the way I know you already are aware of this, more for those that don't.
        gpderetta 2y ago
        > It is only taking a couple of decades to get there. I don't know how to break it to you, but the Eighties were 40 years ago :( In any case I was wondering if Hoare, in addition to bound checkings, felt as strongly about the so called temporal safety, but his words are unambiguous: he is not just rejecting any form of Undefined Behaviour, he wants anything that passes static checking to have useful valid semantics, reminiscent of the "well typed programs can't go wrong" maxim.
jeffreygoesto 2y ago
It is a gargantuan endeavour tbh. I am writing safety C++ code for a living and still am undecided if it is a good idea to continue to do so. Safety benefits a lot from understandability and that is undoubtedly better with simple code and a simple(r) language. Trying to keep the legacy code alive through compatibility introduces more than two languages in one, as all the combinations must be understood as well. Wrapping legacy code into bigger "unsafe" blocks and guarding the perimeter of that block is not a bad idea, it creates less mix to reason about. Would allowing only safe references in safety code really hinder adoption?
AlotOfReading 2y ago
The folks talking about profiles and the folks talking about rust-like semantics are speaking past each other. They're not solutions to the same problem. Profiles is essentially "let's formalize the 80% cases of easy static analysis rules and deal with the hard stuff later". It doesn't get you memory safety in the sense of rust where it's safe if it compiles (modulo unsafe).