I think perhaps you and the author have different interpretations of "consistently". You might also differ on whether "safe code" is safe just because it hasn't failed (or been reported!) yet under current inputs.

> They do it as part of a much larger safety process, that is designed to be robust against faults at all levels

So, since we seem to have moderately good success through voluntary adherence to strict guidelines, we shouldn't automate away the possibility of some of these errors entirely when possible? What are the benefits of that approach?

Edit:

I think you can safely ignore my original comment. It's obvious now that I was interpreting it oddly by conflating it with some other comments and positions in this thread. Your comment does a good job of explaining how it is possible to write safe C/C++ consistently (although I might quibble by saying that it is only achieved by ignoring portions of the languages, thus confining you to a dialect of those languages, which is a point in itself to be discussed).

I would delete the original portion, but I believe in acknowledging mistakes rather than hiding them, thus this correction.