It does. Again, the area requiring audit is substantially smaller: just smallstr. And not just because we've extracted it there, but because we statically know that unsafe behaviors are limited to there. (By way of unsafe {} blocks.) I.e., we only have to audit the unsafe code in Rust, vs. all of the code in C.
> (2) smallstr isn't very standard!
Well, the same could be said for C? Rust's stdlib, like Cs, is somewhat purposefully kept small. It could be that someday it'd get added, but there is enough variation in implementation here that I'm not sure it would.
But pulling in a package in Rust is far easier than it is in C.
It might not be "standard", but I do think there's a set of crates in Rust that are what I'd call "well-known". Like Boost in C++ or requests in Python.
> (3) this is glibc, not app code, and you absolutely can't be pulling random libraries into the core standard library in any case.
That seems NIH. I see no reason glibc couldn't pull in static code, if it does the thing that needs doing, and correctly so.
> Basically this seems like excusemaking. Rust in fact has the same problem, because it's a hard problem, and not subject to clean abstraction through the tooling. And it would be good for everyone to admit that fact rather than try to prestidigitize an explanation.
No, Rust provides better tooling to solve the problem. (Even if it must still be solved, and even if you had to manually reimplement smallstr yourself.)
You're just going back to saying "Rust is better than C!" which is true, but uninteresting. The question at hand was whether this bug would have happened in a memory-safe language. And in fact it could have, because it's implementing an optimization Rust can only emulate using unsafe.
This is what drives me bananas about the rust community. The religion around memory safety persists even in circumstances where it doesn't exist. That's a cult, not an engineering effort.
It does. Again, the area requiring audit is substantially smaller: just smallstr. And not just because we've extracted it there, but because we statically know that unsafe behaviors are limited to there. (By way of unsafe {} blocks.) I.e., we only have to audit the unsafe code in Rust, vs. all of the code in C.
> (2) smallstr isn't very standard!
Well, the same could be said for C? Rust's stdlib, like Cs, is somewhat purposefully kept small. It could be that someday it'd get added, but there is enough variation in implementation here that I'm not sure it would.
But pulling in a package in Rust is far easier than it is in C.
It might not be "standard", but I do think there's a set of crates in Rust that are what I'd call "well-known". Like Boost in C++ or requests in Python.
> (3) this is glibc, not app code, and you absolutely can't be pulling random libraries into the core standard library in any case.
That seems NIH. I see no reason glibc couldn't pull in static code, if it does the thing that needs doing, and correctly so.
> Basically this seems like excusemaking. Rust in fact has the same problem, because it's a hard problem, and not subject to clean abstraction through the tooling. And it would be good for everyone to admit that fact rather than try to prestidigitize an explanation.
No, Rust provides better tooling to solve the problem. (Even if it must still be solved, and even if you had to manually reimplement smallstr yourself.)