The best solution to this sort of bug is not using languages that are susceptible to this sort of bug. At the very least, I think it's time to retire the fallacy that we're generally capable of producing sound programs in memory unsafe languages. Just like we don't write code manually checking raw SQL to protect against injections and we don't roll our own crypto when we need to encrypt something or do a key exchange, we shouldn't treat writing safe code in C as something anyone can do by just being vaguely diligent.

I feel like we need for C and C++ what Typescript is for Javascript: Not a language from scratch but something which is as close as possible to the thing everyone is familiar with while doing the thing Rust does. A standard library where everything has the same names, the same kind of C++ objects and templates and RAII etc., change only this and nothing else.

Because otherwise you make people learn 100 other things at once to start using it effectively, and then they don't.

Something like this? http://cyclone.thelanguage.org/wiki/Cyclone%20for%20C%20Prog...

That isn't the thing Rust does, and is slower, so then people won't use it.

The advantage of Rust is that you can produce efficient safe code. The disadvantage is that you have to learn a different language first, which deters adoption.

I'm asking this into the comment section, since I'm curious if anyone has checked:

Does Zig fill this space in any way? It still allows manual memory management but offers more protections, the specifics I'm unclear on.

Zig is something like this for C, but not C++. There are a number of ongoing attempts to do something like this for C++, but it is very hard and they are all way behind Rust in terms of mindshare.

Indeed, I would kill for a proof assistant that integrates with C

Check out the tooling from the seL4 project. I'm aware they used intermediate levels between raw C and the proof assistant, but I don't see why that should be prohibitive.

You do understand that's not a practical solution here, do you?

Implementing webp and similar libraries in another language may not be quick or easy, but having these sorts of issues continue to crop up over and over doesn't feel particularly practical to me; it's just easier to act like every time a critical vulnerability comes up due to memory safety that it's an isolated issue than confront the reality that its a systemic issue and there aren't any easy solutions.

This response is becoming so tiresome

> This response is becoming so tiresome

I'd argue the constant stream of CVEs due to memory unsafety is even more tiresome.

Agreed, I'll stop saying it when we stop having these issues. I don't think people want to confront the fact that there isn't any easier solution, but we're going to keep running into the same thing over and over until we do.

The lack of response is way more tiresome. We keep having the same catastrophic failures decade after decade. Let's do nothing.

ye gads man, did you even read the comment you're replying to?

I did - and I'm not sure how adding those checks here would help. Are you proposing a full library reaudit?