[matthewdgreen]

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.

[albntomat0]

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.

[Lockal]

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.

[vacuity]

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.

[pjmlp]

First profile, then optimize.

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

[antiframe]

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

[flooow]

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

[pjmlp]

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