But "safe" rust at least intrinsically protects from use-after-free, double free, dangling pointers, null-pointer dereferences, out-of-bounds accesses, … You may still have logic bugs of course (though the richer type system expressivity also allows better static encoding of application & domain logic), but these baseline memory-safety issues will only be a problem in specific and tagged `unsafe` blocks rather than throughout the application.

As well as introduce new ones.

If, on the other hand, you rewrite the code line by line from C to Rust (which Rust is actually quite amenable to!), faithfully translating the semantics of the C code into the Rust code (and thereby having to use lots of unsafe{} blocks) then you can avoid most of the problems—what you'll end up with will essentially be the same as what a hypothetical C-to-Rust transpiler would output.

Importantly, you can also translate the test suite in this same way.

After that step is done, you can just refactor the resulting code, replacing unsafe{} blocks with Rust idioms, and then rerunning the tests (which you can leave un-idiomatized) as regression tests.

Even though I am a believer I would love to see some solid evidence of Rust making code safer.

Ah, and not passing it around by address or reference, instead of actually moving ownership.

C++17 is a great improvement, but for it to work out in this context, developers need to actually write C++ instead of "C with C++ compiler".

- std::move out of a unique_ptr x and "*x" is a null pointer dereference,

- take a reference into a unique_ptr, and it becomes dangling if it is held after the pointer is deallocated,

- an T[N] array doesn't get bounds-checked whether or not it is stored in a std::unique_ptr (it is nice that it reduces the number of raw pointers flying around, which likely does reduce the number of out-of-bounds accesses, but it doesn't solve them)

If you want to pay the cost of runtime array checking every time, an impl in operator[] is just a few lines long. Thankfully it is becoming more common to run programs under ASAN in dev mode.

  #include <memory>
  
  int main() {
    std::unique_ptr<int> p = std::make_unique<int>(0);
  
    std::unique_ptr<int> q(std::move(p));
  
    return *p;
  }

> If you want to pay the cost of runtime array checking every time, an impl in operator[] is just a few lines long

This is also a different point, and moving the goal posts.

In any case, which operator[] exactly? AFAIK, neither T[N] nor T* can have a custom operator[] (and getting the bounds of a raw pointer is essentially impossible), and none of the operator[]s of std::array nor std::vector nor std::span do bounds checking (sure, you can use ...::at for the first two, but you have to remember to do that everywhere, going against the default that pretty much every programming language uses).

> Thankfully it is becoming more common to run programs under ASAN in dev mode.

Yes, this is great! However, this is yet another different point, and it is orthogonal to modern C++ and its fancy new features like std::unique_ptr: C++98 code, and even C code benefit from ASan.

    std::unique_ptr<int> foo(new int(10));
    
    void bar(int& x);
    
    int main() {
        bar(*foo);
        return 0;
    }
    
    void bar(int& x) {
        foo = std::unique_ptr<int>(new int(20));
        std::cout << x; // use after free
    }

The list you were responding to didn't include memory leaks.

< barrbrain> atomnuker: I felt good when my patch was done and I had exactly what I set out to write.

< barrbrain> I didn't enjoy the compiler forcing me to fix all my bugs upfront.

There are also advantages other than safety to using a modern systems language that has learned something from the last 30 years of programming language design but doesn't come with all of the baggage of C++.

Bugs don't magically "shift". If you eliminate a class of bugs, it's gone (e.g. memory bugs).

Whether you can still have other bugs (e.g. logic bugs) that's irrelevant, you could still have those in C as well.

I don't think it's particular likely, but there are always trade-offs.

You are implying that not being able to have dangling pointers in Java (and thus eliminating an entire category of bugs) inevitably leads to the new category of bugs of leaking memory by holding on to references. But that is the case in any language that allows dynamic memory allocation. You can leak memory in Rust, C++ and VB if you don't dealloc.

The switch reduces bugs some, and definitely reduces the severity, but I would largely put the bugs in the same category and say it hasn't been eliminated.

In those languages you have "Logic errors" to debug, in C and its direct descendants you have "Logic errors" + "UB errors" + "Memory corruption errors" to debug.

Also having the use of unsafe explicit in the type system, means that it is relatively easy to track down where such issues might occur, whereas in C every line of code can be a source of problems, depending on which compiler and flags are being used.

Again, this applies to all memory safe system programming language, not just Rust.

EDIT: Fixed the NEWP reference, as ESPOL came first and NEWP only replaced it in 1976.

Yes, but now we're discussing only those that practically matter to more than 5 people today.