[rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0

Tobias Müller 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.

Tobi



More information about the Rust-dev mailing list