One example for a safer language developed at Google: https://github.com/google/wuffs

Responses like this are why people still use C when it may make more sense to use a different language. Don’t just tell people, “trust me bro, never use C, there’s never a good reason”. Never make broad claims that leave no wiggle room, because the one thing that is always true is that there will be exceptional cases. Instead of saying this kind of stuff, why don’t you elucidate what circumstances exist where using C makes sense? Microcontrollers, FPGAs, glue code that can expose your API to other programming languages, maintaining an old code base already written in C, etc.

And as an aside, this is also why people don’t take security seriously. Not every bounds overflow will result in my database being breached and/or my computer being pwned. Instead of freaking out every time a bounds overflow or some sort of memory error is found, it may be useful to actually find out what the impact is. Is that code sandboxed? Is it local, or does it have access to the web? Does it request elevated permissions at any point? Does it even need elevated permissions?

There are many factors that can reduce or increase the risk factor of a bug. Security researchers need to start actually explaining the risk instead of blindly proclaiming everything as a “critical” vulnerability.

And everything I’m saying here has no bearing on this specific vulnerability. It’s in response to the general claim that every memory bug is critical.

Many of those devices also have Ada, Pascal and BASIC compilers available, all of which do bounds checking.

Or they can, I don't know, at very least use C++ with std::array and std::span instead of raw C arrays, with the compiler flags to do bounds checking.

On this note, I was really surprised to find Red Hat's OCI runtime is written in C: https://github.com/containers/crun

Is anyone working on a Rust version?

Well runc is in Go, which isn't Rust but at least isn't C.

Yes, and Red Hat has metrics and explanations showing why Go is not exactly ideal here.

And yet I am surprised they chose C as a replacement... hence my question above!

There is https://github.com/containers/youki

For an image decoding library, you'll still need to expose a C API if you want anything to be able to use your library. You could only provide a library for your preferred language(s) but if like Google you're trying to push an all-new format the ecosystem buy-in is a big deal. And obviously you can provide a C-compatible library without writing the library in C, but it's more complexity to handle.

(Edit: I should mention that this is one reason why I really like wuffs, mentioned elsewhere in this thread; it's a safer language that compiles down to C, so you can have mostly the best of both worlds)

If you want a C-style API, that can be had in Rust as well: https://stackoverflow.com/questions/71904069/how-can-i-expor...

Can vouch for the ease of Rust-C FFI. It was very simple for the newbie I was at the time I used it.

I don't think the answer is to do fine-grained bounds checking absolutely everywhere, nor do I think it'll happen anyway. Even "unsafe" code has a coarse type of bounds-checking, the kernel's virtual memory layer, which adds less overhead. C etc is fine if it's not in the same memory space as the safe code.