3 ms·

> 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

> 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 https://news.ycombinator.com/item?id=26307709 [1] https://news.ycombinator.com/item?id=30597750 https://news.ycombinator.com/item?id=30597750 [2] https://doc.rust-lang.org/nomicon/meet-safe-and-unsafe.html https://doc.rust-lang.org/nomicon/meet-safe-and-unsafe.html

deltaonefour 5y ago
> 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.
kazinator 5y ago
> 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
- MaxBarraclough 4y ago
  > 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/ http://www.eschertech.com/products/ [1] https://www.boost.org/doc/libs/1_79_0/libs/safe_numerics/doc/html/introduction.html 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/ https://alexgaynor.net/2019/apr/21/modern-c++-wont-save-us/ [3] https://news.ycombinator.com/item?id=26948129 https://news.ycombinator.com/item?id=26948129

deltaonefour 5y ago

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

kazinator 5y ago

> 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

MaxBarraclough 4y ago
> 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/ http://www.eschertech.com/products/ [1] https://www.boost.org/doc/libs/1_79_0/libs/safe_numerics/doc/html/introduction.html 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/ https://alexgaynor.net/2019/apr/21/modern-c++-wont-save-us/ [3] https://news.ycombinator.com/item?id=26948129 https://news.ycombinator.com/item?id=26948129