[rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0
troplin at bluewin.ch
Tue Jan 14 12:16:04 PST 2014
Lee Braiden <leebraid at gmail.com> wrote:
> On 14/01/14 01:50, Palmer Cox wrote:
> On Mon, Jan 13, 2014 at 12:18 PM, Tobias Müller
> <troplin at bluewin.ch
> <mailto:troplin at bluewin.ch>> wrote:
> Daniel Micay <danielmicay at gmail.com
> <mailto:danielmicay at 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.
More information about the Rust-dev