Check on the fiction section sir. Here is the CS one.
Although I think all the C compilers are safe ish lately. I haven't seen exploits that target defects in output. Usually the error is ID10T located in the prekeyboard device.
Not necessarily a "safe compiler" but maybe safe library for containers and things like that. It seems to me that most if not all major C projects just run sanitizers and static analysers.
All decent C compilers have compilation options so that at run-time any undefined actions, including integer overflow and out-of-bounds accesses, will be trapped.
The only problem is that these options are not the default and most C developers do not use them, especially for release versions.
I always use them, including for releases. In the relatively rare cases when this has a performance impact, I disable the sanitize options only for the functions where this matters and only after an analysis that guarantees that events like overflows or out-of-bounds accesses cannot happen.
Despite the hype, by default Rust is not safer than C compiled with the right options, because the default for Rust releases is also to omit many run-time checks.
Only when Rust will change the default to keep all run-time checks also in release builds, it will be able to claim that by default it is safer than C.
For now, when safety is desired, both C and Rust must be compiled with non-default options.
> Only when Rust will change the default to keep all run-time checks also in release builds, it will be able to claim that by default it is safer than C.
Which checks are you thinking of? The only thing that comes to mind is that integer overflow wraps instead of panics, but given that bounds are checked, it is still going to be a panic or logic bug rather than a buffer overflow.
1. Notably, some sanitizers are not intended for production use. I think this has changed a bit for asan but at one point it made vulns easier to exploit. These aren't mitigations.
2. They're extremely expensive. You need tons of bookkeeping for pointers for them to work. If you're willing to take that hit I don't really understand why you're using C, just use a GC'd language, which is probably going to be faster at that point.
> Only when Rust will change the default to keep all run-time checks also in release builds, it will be able to claim that by default it is safer than C.
The only thing Rust turns off at release is that unsigned integer overflows panic in debug but wrap on release. That wrap can not lead to memory unsafety.
FWIW it is not recommended to use asan+co for release builds. These are designed as debugging tools, if you use them in production builds they may actually open up new bugs. See also:
https://www.openwall.com/lists/oss-security/2016/02/17/9
I don't think anyone has built anything practically usable that is meant for production, though it wouldn't be impossible to do so.
