That being said, you do have a valid point that file format parsing really could benefit from a language with the safety features of Rust.
I've found that prior exposure to C is somewhat negatively correlated with willingness to grok Rust. Something in their mind rebels against it, which is why I say that if you're an "old hand" C programmer who feels that the syntax of Rust is too hard, or the borrow checker is obscure, maybe you shouldn't worry about learining Rust because Rust isn't for you -- it's for your replacement. You're John Henry, the borrow checker is the mechanical spike driver, and no matter how hard you work at it all your programming discipline is just no match.
rocket Crate up to 0.4.6 on Rust uri::Formatter use after free
If only people stopped with the cargo cult nonsense that leads to this absurd belief that adopting a tool is a silver bullet to fix their sloppy practices.
It is a real world CVE of use-after-free on real world Rust code in production.
This demonstrates that, unlike claims from fanboys, mindlessly migrating to Rust does not magically make your code safe and immune to vulnerabilities such as use-after-free, and just like with any other language you still need to know what you are doing.
Its just so completely uninformed and noob-ish to equate _tools_ to what people build with them. The language is not nearly as important as the programmer and the context in which the code was written. Its a very typical new-programmer thing to think language is all that matters, but most programmers with a few years experience understand how little it matters compared to everything else. You guys are basically like those old Christian missionaries who show up somewhere in Africa knowing nothing and insist the locals convert. Totally clueless..
https://doc.rust-lang.org/nomicon/lifetime-mismatch.html
i know the lifetimes are fine, but Rust doesn’t. in a memory unsafe language i would have to model the mutability in my head to ensure the code is fine. i now need to model the lifetime checker and its limitations/false positives _in addition to_ the underlying mutability to understand whether a compiler error is actually a bug in my code or not. and this is in an extremely short & simple program.
a compiler that can truly enforce safety without too many false positives is definitely a win. but for now it seems like a leaky abstraction so it adds complexity instead of reducing it.
https://docs.rust-embedded.org/book/interoperability/rust-wi...
I will probably get upwoted for Libmobi and other C/C++, because Rust is a bit of a waste of time.
Having said that, Rust is a C++ replacement not a C replacement. The biggest selling point of C is being the thing every other language talks and running everywhere including embedded devices with crappy custom compilers.
With both Rust and C++ you still need to write extern "C" wrappers which are suboptimal, even when partially automated, and neither runs everywhere.
The software industry has been dealing with the fallout of these issues for the past three decades. It's about time we moved the bar higher.
By the way, the main data structure of my first large Rust program was simply a vector of a custom struct, optimized for memory footprint. Just like in C, with the same low overhead serialization.
With C, you always have to be careful to not overrun a buffer. The recent NSS vulnerability is a great example of this:
https://googleprojectzero.blogspot.com/2021/12/this-shouldnt...
Even though this code was heavily fuzzed and tested, the problem slipped through. Not possible in Rust. Also, with Rust you can throw away all your sanitizer infrastructure and save all the associated costs.
It is not, they diverged since decades now.
Still, even if this was the case, the programming styles are so different that there’s nothing to gain considering them as any more similar as any two other languages.
AFAIK you always had to cast `void *` in C++ (like the return value of `malloc`).
Idiomatic C code doesn't explicitly cast the return value of malloc
foo *bar = malloc(sizeof *bar);
foo *bar = (foo *)malloc(sizeof *bar);
My understanding is that most implementations of new call malloc under the hood (this may or may not be outdated at this point, I haven't kept up with C++ implementation) and both of these systems introduce a layer of record keeping, so if you're in an extremely memory constrained environment, you may want to use malloc directly.
If you want your code to be noexcept, you need to call malloc and handle the case where it returns null as new can throw (this is UB in theory, but in practice I'm pretty sure everything just aborts) to strip out all the stack-unwinding code.
If you want to avoid the constructor call (for whatever reason).
That was the point of my original comment that C++ and C are not the same language :)