Comment by MaxBarraclough | Hacker News Reader

Comment by MaxBarraclough | Hacker News Reader

Parent Full thread

> Yes it does. Throughout the entire history of C++ has been touted as as a "better C", where "better" includes "safer". This was not just empty marketing; the claims were justified.

You're arguing that C++ makes safety improvements over C. I broadly agree, but that's not the topic at hand. C++ is still quite plainly not a safe language.

Whether it's safer than C isn't the point, but this causes undefined behaviour in both C and C++:

    int i;
    int j = i;

as does this statement:

    int i = 1 / 0;

as does:

    int i = INT_MIN * -1;

as does:

    int i = INT_MAX + 1;

> There are ways of using C++ that are entirely safe, along those lines. [...] No C arrays, no C pointers.

Practically speaking, no, there are not. As I showed above, it's not just arrays and pointers that have safety issues in C and C++. I've rambled before about how there's no practical way to entirely avoid the unsafety pitfalls of C and C++ (short of formal verification). [0][1]

Compare this against the Safe Rust subset of Rust. Safe Rust really is a safe language, at least by their (very strong) definition of the term as guaranteed to be free of undefined behaviour. [2] It's not possible to define a practical subset of C or C++ with this property.

[0] https://news.ycombinator.com/item?id=26307709

[1] https://news.ycombinator.com/item?id=30597750

[2] https://doc.rust-lang.org/nomicon/meet-safe-and-unsafe.html

> You're arguing that C++ makes safety improvements over C. I broadly agree, but that's not the topic at hand. C++ is still quite plainly not a safe language.

The topic at hand is not what your purporting it to be either. You seem to be thinking that the topic at hand is C++ is a language that touts itself to be safer then python. And you are responding to me as if I made that claim. I never did.

Obviously the person you're responding to is making the claim that C++ does tout itself as "safer" then C but not necessarily "safer" then python. But he is responding to an Actual claim you made saying that C++ doesn't tout itself as safe.

> Practically speaking, no, there are not.

Yes, there are. C++ has constructors which ensure that uninitialized objects don't happen.

   mynumber i;        // i is initialized by constructor
   mynumber j = i;    


   mynumber x = mynumber(1) / 0;  // reliable exception is thrown

   i * INT_MAX;       // exception or bignum support in mynum

> Yes, there are.

We're not talking only about read-before-write and integer arithmetic, we're talking about all causes of undefined behaviour.

If it were possible to define a practical subset of C/C++ which guarantees the absence of undefined behaviour, someone would have done so by now, and cybersecurity would be in a much better place. The subset would have a name, would be widely discussed and studied, and we'd be able to point to a large security-sensitive project making successful use of it. I don't believe any of those are the case.

We have subsets like MISRA C and MISRA C++, but they do not offer solid guarantees against UB. We have ambitious formal verification systems such as [0] which are able to reason about C/C++ programs to help the developer produce a solution guaranteed to be free of undefined behaviour.

All that said it would be an interesting project to see how far you could get with a truly safe C++ subset. Like MISRA C, it would be important that there be an automatic way to check conformity.

> C++ has constructors which ensure that uninitialized objects don't happen.

Yes, Boost offers a library for safe integer arithmetic [1] and it's a pity it's so rare for that kind of approach to be taken. A similar approach could presumably be taken to close the door on unsafe union operations, by insisting on using std::variant instead. C++ is particularly amenable to this kind of thing, on account of its operator overloading.

Unfortunately there are many other areas of the C++ language where it's not so straightforward, such as concurrent programming and memory management. Again please see my linked comments where I give a number of examples.

On the memory management front I imagine the way to go would be to ban pointers outright, but permit smart pointers, and have strict rules regarding references.

Also, here's a neat blog post I stumbled across on how std::string_view is unsafe, among other things. [2] edit I now see you've already seen it. [3]

[0] http://www.eschertech.com/products/

[1] https://www.boost.org/doc/libs/1_79_0/libs/safe_numerics/doc...

[2] https://alexgaynor.net/2019/apr/21/modern-c++-wont-save-us/

[3] https://news.ycombinator.com/item?id=26948129

Reply on news.ycombinator.com