4 ms·

> there is no way to guarantee memory safety. Absolutely not true for C++. The language was invented to guarantee memory safety, like Rust was. (The fact that

> there is no way to guarantee memory safety. Absolutely not true for C++. The language was invented to guarantee memory safety, like Rust was. (The fact that people ignore the safety features when coding is irrelevant, people liberally throw 'unsafes' around in Rust and Haskell too.)

ilovecaching 8y ago
C++ wasn't invented to be safe in the same way as Rust or Ada, whose author's saw state of the art safety as a critical tenant of the language. Stroupsoup was, I believe, mostly interested in making C more suitable for large software engineering projects and was more interested in better abstractions, which could lead to better safety. The fact that people can ignore the safety features is the point. Unsafe is a contract, and it only opens a small number of extra "features". It forms the axioms of a proof the your code correctly uses memory. C++ is essentially just patched with safer abstractions, some of which are major improvements, but there is no proof, no rigorous check for safety until runtime from asan or a fuzzer, or other tools that aren't a part of core C++. The biggest issue with the safety of C++, however, is the size of the language. It has become so big and so complicated, and the rules that govern things we take for granted like function name lookups are horrendously unintuitive and lead to unintended consequences.
Thorrez 8y ago
When a simple int foo(int x) { return x+1; } leads to undefined behavior (aka the standard says the program can delete your hard drive) if x is too big, that's not a language that guarantees memory safety.
- dearrifling 8y ago
  That has nothing to do with memory safety, that's just plain UB.
  - Thorrez 8y ago
    According to the spec, it can lead to all the same problems that any UB leads to, including all the problems that any memory unsafety leads to. The code is allowed by the spec to cause memory unsafety. But to list some direct memory unsafety possibilities: indexing off the end of an array, indexing off the end of a vector, dereferencing a bad pointer, dereferencing a null pointer, dereferencing a bad iterator, double delete.
- fxfan 8y ago
  How does rust handle this?
  - Thorrez 8y ago
    I've never used rust, but from what I've heard, it crashes in debug mode, and wraps (two's complement) in release mode.
    - deleted 8y ago
      [deleted]
    - steveklabnik 8y ago
      That’s the default semantics, yes.
    - vardump 8y ago
      > it crashes in debug mode, and wraps (two's complement) in release mode. Well, that's indeed a nice feature in debug mode. Mostly wraparound is undesired and wraparound bugs are pretty common. Shame the performance cost is too much to do same in release. Whenever wraparound semantics it is actually wanted, one can use an appropriate type.
pjmlp 8y ago
The language was invented so that Bjarne after his experience having to rewrite Simula into BCPL, never had to go through such a low level language again in his life. Plenty of interviews where he states this, including some of his books.

ilovecaching 8y ago

C++ wasn't invented to be safe in the same way as Rust or Ada, whose author's saw state of the art safety as a critical tenant of the language. Stroupsoup was, I believe, mostly interested in making C more suitable for large software engineering projects and was more interested in better abstractions, which could lead to better safety. The fact that people can ignore the safety features is the point. Unsafe is a contract, and it only opens a small number of extra "features". It forms the axioms of a proof the your code correctly uses memory. C++ is essentially just patched with safer abstractions, some of which are major improvements, but there is no proof, no rigorous check for safety until runtime from asan or a fuzzer, or other tools that aren't a part of core C++. The biggest issue with the safety of C++, however, is the size of the language. It has become so big and so complicated, and the rules that govern things we take for granted like function name lookups are horrendously unintuitive and lead to unintended consequences.

Thorrez 8y ago

When a simple int foo(int x) { return x+1; } leads to undefined behavior (aka the standard says the program can delete your hard drive) if x is too big, that's not a language that guarantees memory safety.

dearrifling 8y ago
That has nothing to do with memory safety, that's just plain UB.
- Thorrez 8y ago
  According to the spec, it can lead to all the same problems that any UB leads to, including all the problems that any memory unsafety leads to. The code is allowed by the spec to cause memory unsafety. But to list some direct memory unsafety possibilities: indexing off the end of an array, indexing off the end of a vector, dereferencing a bad pointer, dereferencing a null pointer, dereferencing a bad iterator, double delete.
fxfan 8y ago
How does rust handle this?
- Thorrez 8y ago
  I've never used rust, but from what I've heard, it crashes in debug mode, and wraps (two's complement) in release mode.
  - deleted 8y ago
    [deleted]
  - steveklabnik 8y ago
    That’s the default semantics, yes.
  - vardump 8y ago
    > it crashes in debug mode, and wraps (two's complement) in release mode. Well, that's indeed a nice feature in debug mode. Mostly wraparound is undesired and wraparound bugs are pretty common. Shame the performance cost is too much to do same in release. Whenever wraparound semantics it is actually wanted, one can use an appropriate type.

pjmlp 8y ago

The language was invented so that Bjarne after his experience having to rewrite Simula into BCPL, never had to go through such a low level language again in his life. Plenty of interviews where he states this, including some of his books.