Additional timeline info, as I was curious myself. WebP is old enough that a memory safe language was not a feasible option when the project started.
Android 12 was the first version to support Rust code, and came out in 2021 [0, link talks about the first year of integration].
On the iOS side (which also was affected by this), Swift 1.0 came out in ~2014.
As far as I can tell, Chrome doesn't yet support a memory safe language, but do have a bunch of other safety things built in (see MiraclePtr, sandboxing, etc). Since both WebP and Chrome are from Google, this would stop a possible transition.
WebP was announced in 2010, and had its first stable release in 2018 [1].
> Chrome doesn't yet support a memory safe language
In addition to the safety features you mentioned, Chrome supports Wuffs, a memory safe programming language that supports runtime correctness checks, designed for writing parsers for untrusted files. I don’t think it existed at the start of the webp project either, but that’s what I would expect the webp parser to be written in, over Rust or a garbage collected language.
Is Rust in practice a memory safe language when you're doing tricks like decoding huffman-decoding huffman tables into buffers? It seems like once you optimize for performance this much, you're liable to turn off bounds checking here or there.
I agree it's definitely possible, and I'm certain we'll see a vuln due to some crazy Rust optimizations in the future.
That said, not switching over to a memory safe language, in my opinion, is letting perfect be the enemy of the good. Folks will still be able to write footguns, but better language choices will prevent bugs in the all the non-crazy optimized parts.
There are already huffman-decoding and some parts of webp algorithms in https://github.com/google/wuffs (language that finds missing bounds checks during compilations). In contrary, according to readme, this language allows to write more optimized code (compared to C). WEBP decoding is stated as a midterm target in the roadmap.
The point of `unsafe` in Rust is that you can generally limit `unsafe` code to a few short functions and encapsulate them in a safe interface. This means less code to review and maintaining strong guarantees in the rest of the safe Rust code.
Incorrect. Semantically, Rust always inserts runtime bounds-checks, regardless of optimization level. The compiler _may_ then remove them as part of an optimization pass, iff it can prove the check is redundant.
Do bounds checks even matter, even for very tight loops? This article [1] seems to suggest that removing the checks can give up to 10-15% speed increase under some circumstances. Worth it? I'd say no.
Ada has the bounds checking, but doesn't (AFAIK) have a safe way to deallocate dynamic memory. At least as of now, there is a proposal to add something like Rust in the future.
It also has memory unsafe concepts like specifying an address for a variable.
No. That is true for the list upthread (well, if you consider runtimes measuring a couple of MB "large", it's reasonable but quite arguable). It doesn't have much correlation with any feature.
Android 12 was the first version to support Rust code, and came out in 2021 [0, link talks about the first year of integration].
On the iOS side (which also was affected by this), Swift 1.0 came out in ~2014.
As far as I can tell, Chrome doesn't yet support a memory safe language, but do have a bunch of other safety things built in (see MiraclePtr, sandboxing, etc). Since both WebP and Chrome are from Google, this would stop a possible transition.
WebP was announced in 2010, and had its first stable release in 2018 [1].
[0]: https://security.googleblog.com/2022/12/memory-safe-language...
[1]: https://en.wikipedia.org/wiki/WebP