Whether you know it or not, you have used libjpeg-turbo. In fact you are probably using it every day, it's just behind the scenes, just like openssl is.
These projects deserve funding, if at least from giants like facebook & co.
These projects deserve funding, if at least from giants like facebook & co.
Absolutely.
Looking at:
https://github.com/libjpeg-turbo/libjpeg-turbo/releases/tag/...
one wonders what possible harm could come from leaving image decompression buffer faults from maliciously crafted jpegs in popular browsers and software unattended.
This is yet another reason a switch to a memory-safe language like unsafe-free Rust is highly imperative.
Guaranteeing memory safety isn't just an overhyped benefit meaningful only to Rust fanboys. It is also one important reason why much code is written in Java, Python, or JavaScript. It is a valuable property for any language to have.
The 100% certainty you use to claim it's absolutely memory safe is the essence of the problem with the rust fanboys.
There is an entire class of bugs common to C and C++ that absolutely never happen in JVM languages, CLR languages, Rust, etc. This particular class of bugs of bugs never happen by design, because the language design simply does not permit them to occur ever.¹
¹ I am obviously of course excluding bugs/exploits/unintentional-loopholes here that are in the JVM or CLR, or in the Rust compiler itself, that permit a program to "break out of its box", so to speak.
Does that mean Swift is unsafe? No.
All this does is create the potential for a memory leak. Which is nowhere close to being in the same category as a buffer overflow exploit.
Also, I suppose one could write a garbage-collected pointer library for Rust, which adds cycle detection (and auto-deletion) on top of ARC.
There's a reason https://github.com/libjpeg-turbo/libjpeg-turbo/tree/main/sim... is filled with assembly files with conditional loading.
With all the hyper-optimized assembly in there, it's probably still more efficient even with the container penalty (which, tbh, is close to zero on Linux these days).
WUFFS is a special purpose language for Wrangling Untrusted File Formats Safely:
WUFFS pays a high price (loss of generality) for a valuable reward (compile time assurance of memory safety, very high performance) and it makes no sense for people to hand roll this sort of software in C when they should use WUFFS.