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.