Last year saw a proliferation of talks and articles about safety in C++. Lucian Radu Teodorescu gives an overview of these and presents a unified perspective on safety.
  • Tobias Hunger@programming.dev
    6·
    8 个月前

    Governments triggered this entire discussion with their papers and plans to strengthen cyber defenses. The article states that some experts ask for our industry to be more regulated in this regard.

    I am surprised that possible regulations are not even listed as a factor that in the decission to stay with C++ or move to something else.

    Sure, COBOL is still around after decades, but nobody ever tried to pressure banks into replaceing that technology AFAICT.

    • lysdexic@programming.devOPMEnglish
      1·
      8 个月前

      What I find surprising is that there are a lot of steps between a free-for-all and state intervention through regulation that those experts seemed to have skipped altogether, such as voluntary auditing, state-sponsored industry initiatives to specify best practices, invest in the development of static analysis tools and memory profilers, or making vulnerable companies liable for the consequences of attacks.

      But no, they jumped straight into state-imposed regulation. Because keeping people out is a solution?

      • Miaou
        2·
        8 个月前

        Because industries don’t do shit until forced to. People have been writing code for decades and virtually nothing has been done on this topic, so government has to regulate.

        Let’s ask Boeing about self regulation, for instance

      • Tobias Hunger@programming.dev
        2·
        8 个月前

        There is no regulation at this time. There may not be regulation ever. Before there is any regulation we will see nudging into the “right” direction. Suggesting that companies define a memory safety roadmap could be considered as the very first nudge, or maybe not:-)

        All I wanted to say is that ignoring the possibility of regulation in such a text seems a bit short-sighted to me.

  • arendjr@programming.dev
    3·
    8 个月前

    One major selling point for C++ for new projects is efficiency. People are still skeptical that other languages can truly compete with C++ in that space. For example, people that need low latency (game development, trading, etc.) or are into HPC, may never be convinced to switch away from C++ because of this reason. We still don’t have enough data to argue if another language that provides safety can compete with C++ in this area.

    While I can agree we don’t have sufficient data to make hard conclusions on this front, I think there are enough early indications that point to Rust being able to stay on par with or even outperform C++ in this regard:

    • Google, Firefox and Microsoft report performance improvements from migration to Rust. Some of this was attributable to having a better understanding of the problem domain upfront, thus giving an opportunity to choose better data structures. But a large part was also because choosing Rust obsoleted the need for other safety techniques that had a higher runtime impact, such as Google’s MiraclePtr or even sandboxing.
    • Crypto-traders have already massively adopted Rust as their language of choice, providing evidence the language is fast enough for their use cases. It seems a matter of time before traditional traders make the switch.
    • Rust ownership model avoids issues with possible memory aliasing that are inherent in C and C++. This enables compilers to apply optimizations they cannot apply otherwise, leading to higher theoretical throughput. Meanwhile, areas where Rust is theoretically slower (such as mandated bounds checking) are also applicable to C++ whenever safety is prioritized.
    • lysdexic@programming.devOPMEnglish
      11·
      8 个月前

      While I can agree we don’t have sufficient data to make hard conclusions on this front, I think there are enough early indications that point to Rust being able to stay on par with or even outperform C++ in this regard:

      I’m skeptical of these claims, not because X or Y is better or worse, but because milking the last drop of performance has far more to do with software architecture than it has to do with the programming language per se.

      Also, I think this sort of argument always leads to specious reasoning. C is the undisputed performance lead, and you surely do not see Rust proponents using benchmarks to argue they should rewrite all Rust code in C.

      • porgamrer@programming.dev
        2·
        8 个月前

        C is the undisputed performance lead

        This sounds like it would be hotly disputed by almost anyone you said it out loud to, even if you said it 40 years ago.

        • lysdexic@programming.devOPMEnglish
          13·
          8 个月前

          This sounds like it would be hotly disputed by almost anyone you said it out loud to, even if you said it 40 years ago.

          I think you’re expressing uninformed and uneducated opinions.

          Even Debian’s computer language benchmarks game showcases C consistently outperforming Rust, with some notable exceptions in some key benchmarks.

          And Rust was not a thing 40 years ago.

          Anyway, I think I proved my point with regards to the silly idea that performance is a decisive trait. You cannot have your cake and eat it, too.

      • arendjr@programming.dev
        1·
        8 个月前

        I agree performance is much more about architecture than language performance at the bare metal. But especially in security-conscious environments C and C++ lose in performance because architecture decisions include mitigations that need to compensate for the languages’ lack of safety. I know of several projects where C or C++ code is either delegated to separate processes with reduced permissions or to WASM sandboxes. Firefox even famously used to compile C++ code to WASM and then used a WASM ahead-of-time compiler to turn it back into native code that still maintained properties of being sandboxed. Such measures gravely impact performance however, so in those instances C is far removed from having a performance lead.

  • eveninghere@beehaw.org
    2·
    8 个月前

    We can improve security via updating the C++ language forever, but the threat remains in the package management, and I couldn’t find that discussion in this article.

  • porgamrer@programming.dev
    1·
    8 个月前

    Great article, though I would love to see a summary that breaks down the possible approaches and what the status of each is.

    I’m quite interested in the research that adds runtime provenance info to pointers, so you store (for example) a region ID that lets you do bounds-checking on pointer arithmetic. It doesn’t achieve Rust-level safety, but means buffer overflows can only get so far before they segfault.

    I know there are many cases where ordinary code will cast mystery memory into a pointer, but in modern C++ these generally live in templated library code. If we introduce a Rust style “unsafe block” to disable compiler warnings on these, I think I could refactor most of the others out of the legacy code I maintain.

    I don’t know how many exploits this would prevent in practice though. I have no expertise there