Your comment would be better without the last sentence.
And the handling of that CVE does illustrate a key difference between Rust and C++. Rust says "it's our fault if we get the intuitive semantics wrong". C++ says "it's your fault for relying on your intuition". It does no good to pretend there's no difference between the two philosophies.
You seem to be saying Rust patches up the most obvious Posix holes but leaves the more subtle ones, to make it seem more secure without, in fact, being more secure.
If you fix some issues but not others (the fact that we aren't being specific about which POSIX issues we're referring to is driving me crazy, but anyway) you have in fact improved security. The "well, if it can't be perfect, there's no point in doing anything at all" attitude is deeply pernicious, and it would be unfortunate if that is what C++ has adopted.
If you fix a filed complaint, but leave in place the same means to break in as before, that is what we call "security theater", which has a well-deserved poor reputation.
There are so many, if Rust wants to do it right across the board, then for every POSIX API where the behavior isn't fully specified, they need to provide a correct way.
the libc crate exposes functions in Rust, some are safe, others aren't, you don't call the libc crate function through FFI. (The libc crate indeed calls the underlying libc through FFI but this isn't the same thing!)
There are a lot of things that cannot be exposed in safe Rust (and that's OK, that's what `unsafe` is made for).
There's a big difference between “using this is unsafe, and you must use the `unsafe` keyword and be sure to manually check your invariants” and “oops you used a safe function from the standard library and it was in fact unsafe too bad”.
We're literally in a thread about a guarantee that Rust kept (but C++ didn't) for filesystem APIs.
So "related to memory corruption" is either a deliberately vague statement such that you can count "deleted files you didn't intend" as "memory corruption" or you're missing the true extent of what's offered here.
Type safety could also be argued to just be about "memory corruption" but because of the newtype idiom Rust's type safety ensures all sorts of critical things that you wouldn't associate with "memory corruption" as it is ordinarily understood, starting with obvious built-ins like str really being UTF-8 and Saturating<i16> really having saturating arithmetic operations despite only being an ordinary 16-bit integer - but building up to Mutex<Thing> genuinely not letting you access the Thing without taking the Mutex, and GPIO types that reflect the reality that this GPIO is either a PCM device, or it is a serial port, but it by definition is only one thing at a time and must be explicitly switched between them if that's what you want to do.
> A fake guarantee, because it is impossible to actually enforce it for every filesystem in use.
For some time now the situation is that a POC exists which works just fine against C++ programs, but no longer works against Rust programs with current Rust. That seems much more like a real guarantee to me than a fake one.
> If Rust safety goals is to be dependent typed safety language
Rust does not offer full-blown dependent types today, and so far as I know has no plans to do so, although it would be convenient if it was easy (it isn't easy).
But (safe) Rust does have working type safety and this already meaningfully makes us safer as I explained already.
Until, of course, a very slightly different POC is coded that works against Rust programs built with current Rust.
Erecting a fencepost and expecting attackers to run headlong into the fencepost and knock themselves out is not security. Actual attackers just go around.
Again, it is unwise to explain things you do not understand to people who do understand them.
Of course, just "a very slightly different POC". And let me guess, because you are "people who do understand them" you could certainly conjure up such a thing, but alas, you just don't have the time right? So, Rust is vulnerable to an imaginary attack that Nathan Myers claims to be able to write, while C++ is vulnerable to an actual attack that we know works.
As to the fencepost analogy I will note that Rust fixed the problem a little over a month ago and ever since C++ proponents have been running into that particular fencepost quite certain that the resulting brain damage is proof of just how smart they are for not fixing bugs.
Almost this, but it's slightly broader: Rust guarantees means you won't hit an undefined behavior in safe Rust (as long as the underlying unsafe Rust is correct, this is an important caveat). This isn't equal to memory corruption, especially because optimizing compilers exist and UB can lead your code to be completely miscompiled (which is both dangerous and really annoying to debug).
Also, while this isn't a guarantee, Rust's type system and control flow regarding error handling can help avoid mistakes you sometime see in C (the infamous “goto fail” for instance). Obviously, since C++ is already much more expressive than C, Rust is less of an improvement from C++ in that regard.
And the handling of that CVE does illustrate a key difference between Rust and C++. Rust says "it's our fault if we get the intuitive semantics wrong". C++ says "it's your fault for relying on your intuition". It does no good to pretend there's no difference between the two philosophies.