3 ms·
If you scan through the source (on github), the most notable thing is the lack of the "unsafe" keyword. I've seen too many people basically transliterate from C
by pslam 10y ago
If you scan through the source (on github), the most notable thing is the lack of the "unsafe" keyword. I've seen too many people basically transliterate from C to Rust, along with all the unsafe operations. This one is pretty much unoptimized, but still seems to be performant enough, and doesn't do anything "unsafe".
That's not to say you could just throw this into the back-end of a public-facing website. It's still going to panic (abort) if someone unexpected happens, and it's still going to chew indeterminate amounts of CPU, memory or storage unless sandboxed (maybe even just ulimit). And there's still the danger one of the Rust standard library functions has a flaw in it. But this is the kind of starting point you wouldn't get with the plain C equivalent.
- technion 10y agoGiven the history of vulnerabilities in tools like ImageMagick, that panic might still be a better position than an exploitable memory bug.
- conradev 10y agoIf you run it in a spawned thread, the thread will actually just unwind and disappear if it panics (by default). But to detect panics, you can use `afl.rs` to fuzz a parser: https://github.com/frewsxcv/afl.rs#user-content-trophy-case https://github.com/frewsxcv/afl.rs#user-content-trophy-case
- EugeneOZ 10y agoGiven the fact you can avoid panic and exit safely, all panicking is just laziness ;)
- jakub_h 10y agoIsn't it the case that at least some unsafe features in C actually prevent compiler optimizations? Being safe should not necessarily mean being slower. Sometimes restrictions are enablers for better compilers.