> To my recollection, most of the unsafe-rust-specific pointer aliasing bugs which have been found in std or other popular rust libraries happened because the code was written first and then the rules got stricter!
This is exactly why I have mentality. Rust is a language that grows fast and is exceedingly ambitious. Moving fast tends to break things. And while this is certainly a far less frequent occurrence than C/C++ compilers implementing new optimizations that break on UB that has historically compiled correctly, at least C/C++ compilers usually recognize that these optimizations can be dangerous to bad code and provide -O2 to keep bad codebases afloat.
In general, I think the C/C++ spec was wise in being very explicit about what it does not guarantee (though its choice of what might've been questionable). If you never allow something in the first place, it's only the programmer's fault for doing it. What everyone can agree on, though, is that C/C++ compilers not providing tooling & sane defaults that help guide programmers towards good code and better practices was and is an absolute travesty. Things like UBSan have come too little, too late to restore C/C++'s reputation. UBSan and Rust's Miri are some awesome stuff, though.
> What was really meant (or should have been meant) by the original claim is that unsafe rust introduces new rules which must be followed w/r/t pointer aliasing. But it is far from clear that the marginal new rules introduce more unsoundness than the kinds of bugs which rust prevents, in fact it seems rather unlikely. Most memory bugs seem to be the ones that are bugs in all languages, like use-after-free, etc.
I definitely worded things poorly, but exactly. C/C++'s UB is absolute insanity, but it's well defined insanity. The workarounds are all well known, even if they're monstrous abominations. But playing language lawyer with Rust is not only a lot harder since it's underdefined, but there are plenty of things that simply don't have (known) workarounds for. "If it compiles, passes tests, runs correctly, and even passes Miri, then it can't be UB... right?"
But thankfully Rust is optimistic and strives for improvement, so we have things like the Rustonomicon[0] to guide programmers towards sounder `unsafe` code. Unfortunately...
> Warning: This book is incomplete. Documenting everything and rewriting outdated parts take a while. See the issue tracker to check what's missing/outdated, and if there are any mistakes or ideas that haven't been reported, feel free to open a new issue there.