Reply to post: Re: Explain this to me, please

Re: Explain this to me, please

You can have all the memory safety guarantees in the world.

The second that you are able to poke around in / peek at a memory location under your control ("dereferencing a pointer"), then all those safety guarantees go out the window. Because now I can - accidentally or not - overwrite the size of a variable, or write data past its data's upper bound, or make it leak into other nearby memory areas, or access an area that I shouldn't and - if anything is watching at all - trigger a memory access violation (e.g. a null pointer deference).

And in OS terms, that's like saying that your bank is secure, so long as nobody ever want to gets inside. You can't interface with hardware (which will present itself at arbitrary addresses that you need to dereference from, say, the PCI discovery structures), you can't write drivers, and you hit massive performance problems because you end up having to pass information around *everywhere* rather than just refer people to it.

Rust has an "unsafe" mode / command / keyword for exactly this. The second you use it, all bets are off (it's "official" and they know you have to use it, which is why it exists, but they literally say that you have to flag it as unsafe because then YOU have to check your code is right, not the compiler, and if it's wrong, that's not Rust's problem, and they can't stop you interfering with the other "safe" Rust code at that point!).

If it was easy to write an OS kernel, filesystem, hardware device driver, etc. without dereferencing pointers and trusting/interpreting the data therein, then we would have moved on from C before the UNIX era finished, let alone now.

For applications, sure. If they use sensible formats and do everything right they may never need to use an "unsafe" function. But the bits that actually make your computer work are dereferencing third-party pointers that are just handed to them all the time. Every time you see a C-style (cast). That wouldn't work. Every time you receive nothing more than a memory location from hardware and need to use it by pretending/assuming it's something else (e.g. DMA accesses, PCI hardware discovery, framebuffer locations, etc.). That wouldn't work.

Guess where most of all the problems come, for someone writing an OS, especially if it includes third-party hardware support by other-people's drivers?

Did you know, for instance, that 3DFX drivers for Windows 95, etc. literally allowed DMA of the entire memory range of the machine? So by installing the driver for your graphics card, someone writing a game that runs as even a lowly unprivileged user could have queried the graphics driver in such a way that it allows complete unrestricted, unmonitored access to every byte of the computer's memory. Nobody noticed until years later (mostly because looking at driver code is hard, purely because of the safety you need to reimplement everywhere that would normally be in the compiler but with holes poked for what you need to do).

And the second you start using "unsafe" functions, you are actually able to break all the guarantees of "safe" functions throughout the rest of the program.

If memory safety was easy, Java would be secure.