Isnt this whole category of bugs easily avoided by using

1. _SECURE_SCL on windows

2. _GLIBCXX_DEBUG on glibc based toolchains

Those do not remove any bugs; it just changes how they are handled (ignore and hope for the best vs print diagnostic and terminate program, and the latter not in all cases)

Assuming that tests exist, and have good coverage, wont the checked iterator implementations mentioned above catch most issues with invalid iterators?

I don't know of any large, widely used, security critical, heavily scrutinized C++ program that uses those flags in production. I also don't know of any such C++ program that hasn't had game-over use after free bugs. So the answer to your question is somewhere ranging from "we don't know, but unlikely" to "no".

A big part of what makes Rust great is that it catches those issues at compile-time, no test coverage required, no extra run-time checks required (not that it moots tests, of course). In my experience so far this is a very powerful ally to have when writing software, as it's very useful to surface those issues as early as possible.

EDIT: Also:

> Assuming that tests exist, and have good coverage

That's a very big assumption. Granted my current job is often to clean up codebases that are the opposite of that, so maybe I've got a bias here.

For some definition of ‘good coverage’ and ‘most’: yes.

I do not think 100% coverage on the code you write alone is enough to get to ‘all', though. For example, if your test declares a vector and calls a function that does

    v.erase( i, v.end());

with i == v.end(), you get 100% coverage, but in production, that part of the code might be called with i == v.begin(), and that invalidates all iterators on the vector.

No. You can dereference those "safe" iterators into dangling references.