4 ms·

This example is a bit of an outlier since it's so small, but a larger program is going to need proportionally smaller amounts of unsafe code. Remember, just bec

This example is a bit of an outlier since it's so small, but a larger program is going to need proportionally smaller amounts of unsafe code. Remember, just because it's marked unsafe, doesn't mean it's not rust. It's just that for doing low level micro-controller type things, you're explicitly addressing parts of RAM (or memory mapped I/O), and that means creating your own pointer.

chubs 7y ago
So is it the case that you only need 'unsafe' for some of your codebase where you're eg bit-banging, or using peripherals, or whatever - but the majority of your logic is running in normal 'safe' mode?
- littlestymaar 7y ago
  That's right. For instance, in the redox-os kernel, there is less than 100 places where unsafe is needed : https://doc.redox-os.org/book/introduction/unsafes.html https://doc.redox-os.org/book/introduction/unsafes.html.
- mlindner 7y ago
  And to be more specific you'd ideally write an interface implementation that does that bit banging for you such that you call those functions from your safe code.
- PudgePacket 7y ago
  Some amount of unsafe is impossible to avoid for doing certain things. Rust unsafe allows developers to focus their memory auditing efforts, rather than existing languages where _everywhere_ must be checked. Here's an example. The Rust standard library has unsafe code to do things like allocate memory and read from files. However, it provides a safe abstraction that my code can use "safely" and be confident I won't encounter any memory errors. Or if you're writing some kind of concurrent data structure, you want to be doing pointer and memory shenanigans for efficiency, but you'd make a safe API for consumers of the data structure. I think a lot of people are scared initially seeing something like "unsafe". It's kind of equivalent to just regular C/C++ land... It doesn't automatically mean "The program will now eat your memory".

chubs 7y ago

So is it the case that you only need 'unsafe' for some of your codebase where you're eg bit-banging, or using peripherals, or whatever - but the majority of your logic is running in normal 'safe' mode?

littlestymaar 7y ago
That's right. For instance, in the redox-os kernel, there is less than 100 places where unsafe is needed : https://doc.redox-os.org/book/introduction/unsafes.html https://doc.redox-os.org/book/introduction/unsafes.html.
mlindner 7y ago
And to be more specific you'd ideally write an interface implementation that does that bit banging for you such that you call those functions from your safe code.
PudgePacket 7y ago
Some amount of unsafe is impossible to avoid for doing certain things. Rust unsafe allows developers to focus their memory auditing efforts, rather than existing languages where _everywhere_ must be checked. Here's an example. The Rust standard library has unsafe code to do things like allocate memory and read from files. However, it provides a safe abstraction that my code can use "safely" and be confident I won't encounter any memory errors. Or if you're writing some kind of concurrent data structure, you want to be doing pointer and memory shenanigans for efficiency, but you'd make a safe API for consumers of the data structure. I think a lot of people are scared initially seeing something like "unsafe". It's kind of equivalent to just regular C/C++ land... It doesn't automatically mean "The program will now eat your memory".