3 ms·
Any codecs or anything like that seem like a screamingly good target. Right now they're one of our most egregious sources of security vulnerabilities (mostly d
by Jetrel 5y ago
Any codecs or anything like that seem like a screamingly good target.
Right now they're one of our most egregious sources of security vulnerabilities (mostly due to a lot of hands-on bit-twiddling that results in a lot of possibilities for overflow). It's gotten bad enough that a number of system developers (browsers, OSes) have been shifting to a model where codecs are strictly sandboxed, and just get a single binary input blob, and a single output blob, and don't get any other kind of access to the system they're on - it's a scorched earth problem, but it really is that bad.
The thing about trying to write one with Rust is, if you actually 'went with the flow of the language' and didn't just immediately pop into `unsafe`, you'd be able to write a really safe codec.
-but-
The real payoff is that the performance would be surprisingly good - usually a suggestion like the one I just made would absolutely wreck performance, but one of the big things about Rust is that because it lets you describe what your intent is as a programmer in such higher-level terms (despite being a machine-level language), it gives the compiler a lot more information about the scope of your intent, which opens the floodgates to potential optimizations.
For a really easy example - Rust does all variables as "immutable by default". When you're programming in C, and something is compiling your code, there are tons of opportunities where you'd go "oh, well we already calculated this, why don't we just cache it?" But the compiler can't, because it doesn't actually know what you, the human, know - that that thing won't change. Because that knowledge is available to the compiler through Rust, the compiler actually DOES know, so tons of things can get inlined, cached, and otherwise optimized for you which you'd otherwise have to do by hand.
Usually when people do these sorts of things by hand, they'll ace a couple key optimizations (usually things that show up in profiling hotspots) and completely overlook hundreds, even thousands of other potential optimizations.
There are tons of other "high level intent" things that give the compiler more info it can use to optimize, but the "immutability by default" one is a really easy one to explain.
- tialaramex 5y agoFor a codec, WUFFS might be a better fit than Rust. https://github.com/google/wuffs https://github.com/google/wuffs In Rust, if I have two u8 variables and I add them together, Rust will try to figure out if it's sure at compile time that this is an overflow and if so reject it, but otherwise I get a binary which might have an overflow in it. But in WUFFS when you add those variables together, WUFFS wants you to justify why that can't overflow, or, tell it that you know it does overflow and you want wrapping or whatever. As a result, WUFFS gets to be very confident the resulting (awful, machine generated) C is safe and correct. As you observed, this sort of confidence also permits a lot of performance tricks. WUFFS has some very impressive (ie better than existing Rust code) benchmark scores for the (much simpler) codecs like JPEG or PNG but I don't think there's any reason it couldn't shoot for MPEG or beyond. WUFFS is no rival to Rust. It doesn't have IO for example. Which is fine, your codec implementation shouldn't do IO. WUFFS deals in blobs of bytes. Bytes you got over the network or from a file go in, and bytes represented a decoded image, decompressed file, or whatever come out.