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.

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.

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.

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.

people like you are holding back software and security by decades.

in theory could someone do it? yeah, just like in theory someone could use unsafe and return a raw char pointer for some reason.

but in practice would anyone do it? no.

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.

Rust is a fad among HN-types. It is not used in the real world. You see logic errors reported in C/++ because 99.99% of the world's system code is written in it. The only reason you don't see headlines about logic errors in Rust is because nobody uses Rust in production code. Rust certainly does not prevent you from producing the most dogshit software imaginable, eg. https://jepsen.io/analyses/particledb-1.1.4 , which is far worse than any C/++ database anybody uses.

Rewriting it to Rust is fine attempt, just hard to call it is unix/posix anymore. It may not matter but semantically true.

    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.