setjmp wasn't even supported. I had to use an LLVM intrinsic. This only barely worked if I put the setjmp and the longjmp in separate files.
Why is setjmp such a major issue for you? It's a C language feature, not a "real low level to the metal systems programming" requirement.
If you are calling C or assembly and there is any sort of processor exception, you need to establish a signal() handler and you will need setjmp/longjmp to re-establish a safe stack frame.
Yes, this is a C/assembly thing. But it is also a Linux/BSD/Unix thing. You really cannot call Rust a systems programming language if signal/setjmp/longjmp are not fully supported. It just goes with the territory.
The author focuses on rewriting low-level media decoders in Rust. I have bit of experience in this area. I've been slowly working on an MPEG2 binary subtitle decoder in Rust: https://github.com/emk/subtitles-rs A while back, I ran my subtitle decoder through "cargo fuzz", and I was pleasantly surprised at the results: Close to half a billion fuzz runs found 5 runtime panics, all of which were detected by Rust before…
Is there any way to lessen the burden by automating conversion of straightforward portions of a C codebase to Rust? They seem similar enough conceptually and semantically, if not syntactically, that a lot of boring C code might be fairly easy to translate?
"Rewrite it in Rust" is the new "Stallman was right" thread. Its an echo chamber of fandom. Over time I've come to despise "evangelism" or any kind. I'm sure Rust is great. I just don't think it's news every time a Rust fan says that its great. YouTube lectures of people actually using it? That would be interesting. Interviews of people actively porting a large C project to Rust. That would be interesting. Rehashing…
One of the reasons why I'm super hesitant of learning Rust is the attitude and emotional based opinions of the community. I picked up Python due to my work and I love it and I'd never think I would before trying it. But I also never in my travels seen Python people advertise it negative with " SUCKS! FUCKING IMPOSSIBLE! GIT GUD AND USE PYTHONN!" about ANY widespread or niche language but instead they just keep positively gushing over Python: "how clear", "how succinct", "formatted by significant whitespace", "readable", "simple", "pythonic", "wide array of modules available", etc.
When someone in one message both recommends Rust and says that it's absolutely impossible to ever write correct programs in C or C++ that are more than few lines long what am I supposed to take away from that? Rust itself uses C++ written LLVM, is it unreliable too then? Seriously... And implicitly, anyone liking C or C++ is an idiot and a bad programmer.
Sigh. This again. The Rust language is more than just memory safety. Memory safety is certainly the most prominent and unique feature of Rust, but the language also includes a lot of features that make writing good, bug-free code easier. For example: `Result`, when returned, forces all callees to check for errors. It's all too easy to throw away error codes in C/C++. This is probably one of the most important feature…
> `OsRng` in the rand crate (go ahead, try to write a function that safely reads urandom in C). Nowadays, you should just call getentropy ( http://man7.org/linux/man-pages/man3/getentropy.3.html ) instead of trying to read from /dev/urandom, unless you have special requirements.
Great example! OsRng will use that system call, if it is available.
Is there any way to lessen the burden by automating conversion of straightforward portions of a C codebase to Rust? They seem similar enough conceptually and semantically, if not syntactically, that a lot of boring C code might be fairly easy to translate?
https://github.com/jameysharp/corrode/
That doesn't convert C to Rust. It compiles C into Rust as a target language, bugs and all. Raw pointers in C become raw pointers in Rust.
I don't agree with the underlying thesis: In 15 years, I'll be heartbroken if we're still facing an endless stream of security updates and remote root compromises when all these projects were rewritten in a popular but unsafe language: Rust. There do exist fast and SAFE language out there. With guaranteed memory safety, null pointer safety, concurrency safety, dead-lock freedom, race freedom, and even with normal syn…
That doesn't convert C to Rust. It compiles C into Rust as a target language, bugs and all. Raw pointers in C become raw pointers in Rust.
It doesn't provide any additional safety by itself, but it does provide a good starting point. Once you've Corroded your existing C code, you can then replace the unsafe Rust abstractions (like raw pointers) with equivalent safe ones (like references), one at a time. This way the manual part of the conversion doesn't have to be done all at once.
The trouble with mixing Rust and C/C++ is that you tend to get Rust with C/C++ unsafe pointers. Most of the examples of this pass C raw pointers into rust, Rather than passing a Rust Vec into C. Or even passing STL strings and vectors into Rust. So, instead of passing Rust's array size information into C, they propagate C's lack of size information into Rust. Typical example: [1] pub extern "C" fn count_substrings(va…
You only end up with them in the final program with a naive translation that makes life hard for yourself. Using the native types is much nicer (even ignoring any safety benefits), and so people are naturally encouraged to do so. For instance,
- the C interface can easily be thin wrappers around pure "nice" Rust functions, that just do the necessary unsafe conversions
- and, whether or not that is used, when a function is no longer being called from C (that is, everything that calls it has been converted to Rust) the arguments can be switched to something more natural and strong static typing will point out all the places that need to be updated.
I cannot believe that a pure Rust codebase would want to be passing raw pointers around. And the alternatives don't seem at all better: only ground-up complete-rewrite migrations (hard to justify so often won't even start) or not migrating at all (meaning one has a C codebase that is still full of unsafe pointers).
As someone who really likes C and C++ I feel like the biggest reason for me not even thinking of Rust as a viable language right now is the community attitude. It seems so damn hostile to C and C++. Anyone who thinks C and C++ is viable is a misguided idiot, bad programmer, writing unsafe software, etc. to these people. Some badass below even just said that "writing C++ code longer than a few lines without UB is huma…
I think you see some of that since quite a few people have spent decades in C/C++(myself included) and have had exposure to experiencing these exact problems. I'm still a huge fan of C++ but Rust gets me to where I want to go with C++ with much less fuss and a lot more confidence.
I'm a big fan of Python lately but neither I nor Python community at large goes "you fucking scrub, use Python, fuck you, wtf are you doing, stop making broken progs for ppl and wasting your time, omg, obsolete shit you use" and instead highlight upsides of it like readability, plentiful modules, widespread use of it, etc. Meanwhile Rust community seems full of negative advertising in the tone of "fuck C, fuck C++, Rust is safer and better, always, for everything". I see this every time Rust is brought up, without exception. Like WTF? I can understand people disliking C, C++, Lua, whatever, but not going batshit insane over them and saying you need stars to align to write a C program that isn't broken and that to write an unbroken C++ program is impossible...