4 ms·
I think these are just general pitfalls that happen when you port something. Also thinking everything is safe from a security perspective because you don't use
by carlmr 2y ago
I think these are just general pitfalls that happen when you port something.
Also thinking everything is safe from a security perspective because you don't use the keyword `unsafe` seems kind of naive to me. For one safety and security are two separate issues. Also this assumes you really did not understand why Rust has the keyword in the first place and what it's used for.
Obviously Rust can't prevent all logic errors, and doesn't promise to. If you adhere to idiomatic Rust (e.g. using sum types to make impossible states not representable) you'll probably prevent quite a few. But if you port line by line it won't be idiomatic.
Rust does offer a lot of error checking at compile time that you only get at runtime with a combination of ASan, LSan, UBSan, TSan, MSan in C. But it doesn't mean you can stop thinking entirely.
- smj-edison 2y agoOh for sure! It does take understanding the idioms of the language you're porting to, and rust only guarantees memory safety when (iirc) 1. Being in an interrupt free and linear memory environment, and 2. All unsafe code maintains invariants (XOR mutability, etc). There's some others but I can't think of them off the top of my head. But, I wouldn't say this article is only about porting in general. It's very specific in using example drivers written for Linux (which is very different than application C) and showing pitfalls _specifically_ when going to rust. For example, in one of the later parts it talks about Rust mutexes, which are RAII. If you lock twice, you'll have a double fetch that can cause a race condition. That's not a general rule of thumb for code porting.