Hacker News Reader

Comment by albntomat0 | Hacker News Reader

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].

[0]: https://security.googleblog.com/2022/12/memory-safe-language...

[1]: https://en.wikipedia.org/wiki/WebP

View on HN

> 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.

https://github.com/google/wuffs

Ahh cool! I was unaware of Wuffs. Thanks for sharing!

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.

First profile, then optimize.

Many anti-bounds checker advocates, usually miss the first part.

Rusts bounds checking is done at compile time, so you don't need to turn it off.

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.

[1] https://dropbox.tech/infrastructure/lossless-compression-wit...

And runtime as well, like in any memory safe language.

Is JavaScript a memory safe language?

Yes, and so are Python, Lisp, Haskell, and a million other languages that were available in 2010.

None of those are suitable options for an image decoding library on the range of WebP supported platforms.

Modula-2, Ada, Object Pascal, D would be.

What makes them unsuitabe is lack of widespread compiler support across those platforms, if we ignore how long Ada has been available in GCC.

And Modula-2 is now in GCC as well.

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.

Yes it does, this isn't Ada83 we are talking about.

Well Rust also has unsafe, better not use it.

>None of those are suitable options for an image decoding library on the range of WebP supported platforms.

What makes these unusable for this task?

They need a large runtime and are slow to start up.

Is that true for all memory safe languages? Why?

> Is that true for all memory safe languages?

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.

It is. and so is WASM, but both probably aren't fast enough

I think there is a ~35% hit with emscripten

Reply on news.ycombinator.com