alt Hacker NewsYou’ve kindly finished the thought for me. You now have a “safe” version of C purely by updating the standard and associated documentation. (It’s not actually true that you need to redesign all the APIs in the stdlib. You just need to document the appropriate restrictions on how they may safely be used, just as you would have to do with a Rust function marked ‘unsafe’. It’s trivially possible to write an unsafe-marked Rust function that’s guaranteed to be memory safe if and only if an arbitrary invariant is maintained.)
In reality of course, this is all absurd. No matter how much or how little work it turns out to be, writing reams of standardese and leaving actual C implementations untouched would do nothing to reduce the safety risks associated with C code.
By the way, you’re wasting some energy arguing points that I agree with (e.g. that Rust has a better sorting API than C). My comments here are not anti-Rust. I merely disagree with the claim that Rust code marked ‘unsafe’ is as safe as regular Rust code.
>> It’s not actually true that you need to redesign all the APIs in the stdlib. You just need to document the appropriate restrictions on how they may safely be used [..]
That's exactly the problem. Notice how that C API qsort has basically the same affordance as the Rust sort_unstable (except it is type erased) but it has a lot more restrictions because C was a New Jersey language, what matters is that it's easy to implement. So you need to figure out (for some of the API I expect this may be a many years study) what the requirement are that you're going to document.
Or, which I'm confident will often be faster, reform the API and provide the thing programmers actually wanted anyway, the "Right Thing", which means more work for an implementer of your "Safe C" and also, which was my point, actually does get you a safer result after all.