> The choice of handcoding some low-level string manipulation is similar to the choice of using unsafe rust. One can do it or not.
But most of the time programmers don't make a conscious choice at all. So opt-out unsafety versus opt-in unsafety is a huge difference.
> In practice you need to do some quality control for all code anyway, because memory safety is just a small piece of overall the puzzle.
Memory safety is literally more than half of real-world security issues.
> In practice, it is not hard to recognize the C code which is dangerous
> I see some very high quality C code with barely any memory safety problems
I hear a lot of C people saying this sort of thing, but they never make it concrete - there's no list of which popular open-source libraries are dangerous and which are not, it's only after a vulnerability is discovered that we hear "oh, that project always had poor quality code". If I pick a random library to maybe use in my project (even big-name ones e.g. libpq or libtiff), no-one can ever actually answer whether that's high quality C code or low quality C code, or give me a simple algorithm that I can actually apply without having to read a load of code and make a subjective judgement. Whereas I don't have to read or judge anything or even properly know rust to do "how much of this rust code is unsafe".
But I think even this is likely overstating it by looking at CVEs and not real world impact.
> > > In practice, it is not hard to recognize the C code which is dangerous
> > I see some very high quality C code with barely any memory safety problems
> I hear a lot of C people saying this sort of thing, but they never make it
> concrete - there's no list of which popular open-source libraries are dangerous
> and which are not, it's only after a vulnerability is discovered that we hear
> "oh, that project always had poor quality code". If I pick a random library
> to maybe use in my project (even big-name ones e.g. libpq or libtiff), no-one
> can ever actually answer whether that's high quality C code or low quality C code
> or give me a simple algorithm that I can actually apply without having to read
> a load of code and make a subjective judgement. Whereas I don't have to read or
> judge anything or even properly know rust to do "how much of this rust code is unsafe".
So you look at all the 300 unmaintained dependencies a typical Rust projects pulls in via cargo and look at all the "unsafe" blocks to screen it? Seriously, the issue is lack of open-source man power and this will hit Rust very hard once the ecosystem gets larger and this goes even more beyond the highly motivated first adopters. I would be more tempted to buy this argument if Rust would have no "unsafe" and I could pull in arbitrary code from anywhere and be safe. And this idea existed before with managed languages... Safe Java in the browser and so. Also sounded plausible but was similarly highly exaggerated as the Rust story.
> A programmer being careless will be careless with Rust "unsafe" too.
Programmers will be careless, sure, but you can't really use unsafe without going out of your way to. Like, no-one is going to write "unsafe { *arr.get_unchecked(index) }" instead of "arr[index]" when they're not thinking about it.
> So you look at all the 300 unmaintained dependencies a typical Rust projects pulls in via cargo and look at all the "unsafe" blocks to screen it?
No, of course not, I run "cargo geiger" and let the computer do it.
I think unmaintained dependencies are less likely, and easier to check, in the Rust world. Ultimately what defines the attack surface is the number of lines of code, not how they're packaged, and C's approach tends to lead to linking in giant do-everything frameworks (e.g. people will link to GLib or APR when they just wanted some string manipulation functions or a hash table, which means you then have to audit the whole framework to audit that program's dependencies. And while the framework might look well-maintained, that doesn't mean that the part your program is using is), reimplementing or copy-pasting common functions because they're not worth adding a dependency for (which is higher risk, and means that well-known bugs can keep reappearing, because there's no central place to fix it once and for all), or both. And C's limited dependency management means that people often resort to vendoring, so even if your dependency is being maintained, those bugfixes may not be making their way into your program.
> And this idea existed before with managed languages... Safe Java in the browser and so. Also sounded plausible but was similarly highly exaggerated as the Rust story.
Java has quietly worked. It didn't succeed in the browser or on the open-source or consumer-facing desktop for reasons that had nothing to do with safety (in some cases they had to do with the perception of safety), but backend processing or corporate internal apps are a lot safer than they used to be, without really having to change much.
But most of the time programmers don't make a conscious choice at all. So opt-out unsafety versus opt-in unsafety is a huge difference.
> In practice you need to do some quality control for all code anyway, because memory safety is just a small piece of overall the puzzle.
Memory safety is literally more than half of real-world security issues.
> In practice, it is not hard to recognize the C code which is dangerous
> I see some very high quality C code with barely any memory safety problems
I hear a lot of C people saying this sort of thing, but they never make it concrete - there's no list of which popular open-source libraries are dangerous and which are not, it's only after a vulnerability is discovered that we hear "oh, that project always had poor quality code". If I pick a random library to maybe use in my project (even big-name ones e.g. libpq or libtiff), no-one can ever actually answer whether that's high quality C code or low quality C code, or give me a simple algorithm that I can actually apply without having to read a load of code and make a subjective judgement. Whereas I don't have to read or judge anything or even properly know rust to do "how much of this rust code is unsafe".