Not every C vuln is a memory safety problem.
In Rust, the type of the return value would be a `Result<T, E>`, which means the chain of events that led to this would never have started in the first place.
Edit: at the beginning, crypt always returned a value. So hypothetical Rust return type would be a String, and then it would be retained for backward compatibility. Or something else would happen, this is a complex logic bug triggered by a 25 year old chain of events.
That's what led some people to write code where it crashes without checks. Which is still their mistake. But if the type was something that can't be implicitly used like an always-present value, that would have prevented the situation, even with those same people.
Trying to change a function return type from e.g. `string` to `string?` would make the backwards-incompatible breaking change immediately visible, and break the builds of all code that relied on not having to check it back when it was `string` - at compile time.
But it turns out one can have a compile-time error forthis in C as well: https://godbolt.org/z/8E9z66cfs
Now, the decision to return `"*"` instead of letting poorly written code crash on `NULL` is not good either.
Given how easy it is to just forward that error to the caller, I think most Rust developers would just choose to do that.
That's exactly what you get with Result and Option, it's impossible to forget.
Compare:
char* hash = crypt(key, salt);
// We crash here on the hash derefence, it's no clear from the code
// that we were supposed to check for NULL or that we forgot.
if (!strcmp(hash, expected)) {
}
let result: Result<Vec<u8>, Error> = crypt(key, salt);
// We MUST write this line, which is a very clear signal
// that we can panic here.
// This can be grepped for or forbidden.
let hash: String = result.unwrap();
// if result == expected { would type error
if hash == expected {
}You are really uninformed: different programming languages have very different volumes of bugs per line of code
do you think bugs/loc is the same between brainfuck and rust?
no the study failed to show any difference in bug count for a specific set of common used languages, where C and Python were both part of the dataset.
I don't think programming languages have a big impact on bugs per line when every line is written by a human. Now given that I was talking about bug counts, not severity.
kind of reminds me how the "research" suggests that there are no practical differences between dynamically typed and statically typed languages...except we know from practical experience that there is, and the literature there is horribly flawed.
we have real-world evidence that rust leads to significantly less bugs in the real world
https://blog.google/security/rust-in-android-move-fast-fix-t...
It showed that there's no big difference. From the link:
> Combining corrections for all of these aforementioned items, the reanalysis revealed that only 4 out of the original 11 languages correlated with abnormal defect rates, and even for those the effect size is exceedingly small.
--
> we have real-world evidence that rust leads to significantly less bugs in the real world
no, we only have evidence for memory bugs, that's not what I was talking about
oh right, because c is a crusty old language with barely any features.
Easier to formulate invariants and check/prove them. Better language correlates with safer software.
You are right, C with manual memory management, no lifetime management, lack of phat pointers and a culture of leet has problems with deranged maddening bugs that other languages don't have.
But this bug first shows how inband signaling is bad news usually. But worse it's a failure to adhere to the spec properly. If you implement a library and you don't adhere to the spec you're going to bone someone.
Perhaps even worse is obviously the spec doesn't come with any standard testing framework. That was also the root of Apples infamous goto bug.
let hash = match result {
OK(s) => s,
Err(s) => s,
};
@my-huge-pony does make a good point elsewhere in the thread: if the potential error was not foreseen and the code was written originally to return `String` instead of `Result<String, Error>` then even Rust would be in a pickle.
what will it take to move away from c? older devs retiring. Planck said that "science advances one funeral at a time" and i fear it will be the same for software.
I'll take forking and porting, thank goodness for LLMs.
Rewriting it to Rust is fine attempt, just hard to call it is unix/posix anymore. It may not matter but semantically true.
in theory could someone do it? yeah, just like in theory someone could program a calculator to randomly rm -rf ~ when pressing +.
but in practice would anyone do it? no.