Lee Braiden <leebr...@gmail.com> wrote: > On 14/01/14 01:50, Palmer Cox wrote: > > On Mon, Jan 13, 2014 at 12:18 PM, Tobias Müller > <trop...@bluewin.ch > <mailto:trop...@bluewin.ch>> wrote: > > Daniel Micay <danielmi...@gmail.com > <mailto:danielmi...@gmail.com>> wrote: > > Do you know what undefined behavior is? It doesn't mean unspecified. > > True, but despite beeing so often cited it won't format your hard disk > (even in C). > > Actually, it's possible, at least on systems without MMU protection --- > some embedded systems, for example. Ints are often used (not just in > your own code but in library code) to index a jump table. If that index > is a different number than you expected it to be, you could end up > executing calling random "functions" in memory. Said "functions" could > (and probably would) crash within 1--2 instructions, but even then, it's > not INCONCEIVABLE that those instructions could equate to "1) load hard > drive device number into the first arg register; 2) call the OS format_drive > function".
But this is just as likely with wrapping integers. _Any_ deviation from the expected behavior is as dangerous as UB. > This all leaves the realm of remote possibility and enters the realm of > unacceptable risk, at least for some software on some systems, when you > factor in malicious individuals trying to manipulate what address gets > called and/or what code is sitting at the address called, waiting to execute. > > As I understand it, there are essentially three bugs that can cause a > segfault: 1) write to memory you're not allowed to write to. 2) read > memory you're not allowed to read from. 3) execute code in memory > you're not allowed to execute code from. The third kind of bug is > basically saying "do anything you like computer, I don't care." It's > very much undefined behaviour, very much like calling a function pointer > that's NULL. Mostly, you get a segfault, thanks to the MMU, but in > portable code, you can't depend on that -- either the compiler handles > it, or you have to remember to check everything carefully, treating your > coding environment as a hostile one, full of adversaries. And that's just why I want to help the programmer with those checks as much as possible. Lifetimes and non-nullable pointers do a great job ensuring this for memory management, int overflow is missing such a feature. Tobi _______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
