<div dir="ltr">I agree with Vadim that the world will inevitably become security-conscious -- also safety-conscious. We will live to see it unless such a bug causes nuclear war or power grid meltdown.<div><br></div><div>When the sea change happens, Rust will either be (A)<i> the attractive choice for systems programming</i> or (B) <i>obsolete</i>. Rust already has the leading position in memory safety for systems programming, so it's lined up to go.</div>
<div><br></div><div>The world desperately needs a C++ replacement for real-time, safety-critical software before that ever-more-complicated language causes big disasters. Rust is the only candidate around for that. (Or maybe D, if its real-time threads can avoid GC pauses.) CACM's recent <a href="http://cacm.acm.org/magazines/2014/2/171689-mars-code/fulltext"><i>Mars Code</i> article</a> shows the extremes that JPL has to do to program reliable space probes. Smaller companies writing <a href="http://www.edn.com/design/automotive/4423428/Toyota-s-killer-firmware--Bad-design-and-its-consequences">automobile engine control systems</a> and such will soon be looking for a more cost effective approach.<br>
<div><br></div><div>Companies like Intel see so much existing C/C++ software getting by without overflow safety and conclude it doesn't matter. Let's not let their rear-view mirror thinking keep us stuck. Eventually customers will demand better security whether there's a speed penalty or not.</div>
<div><br></div><div>CPU designers could say they've given us so much instruction speed that we can afford to spend some of it on overflow checking. Fair point. When the software folks have demonstrated the broad need, Intel can speed it up, whether by optimizing certain instruction sequences or adding new instructions.</div>
<div><div><br></div><div>The Mill CPU architecture handles overflow nicely and promises much higher performance, like extending DSP abilities into ordinary software loops like strncpy(). Whether this one takes off or not is hard to say. That little company could use a big partner.</div>
</div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Jun 21, 2014 at 3:43 PM, Vadim Chugunov <span dir="ltr"><<a href="mailto:vadimcn@gmail.com" target="_blank">vadimcn@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><br><br><div class="gmail_quote"><div class="">On Sat, Jun 21, 2014 at 2:42 PM, Daniel Micay <span dir="ltr"><<a href="mailto:danielmicay@gmail.com" target="_blank">danielmicay@gmail.com</a>></span> wrote:<br>


<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>On 21/06/14 05:21 PM, Vadim Chugunov wrote:<br>
> My 2c:<br>
><br>
> The world is finally becoming security-conscious, so I think it is a<br>
> only matter of time before architectures that implement zero-cost<br>
> integer overflow checking appear.  I think we should be ready for it<br>
> when this happens.  So I would propose the following practical solution<br>
> (I think Gabor is also leaning in favor of something like this):<br>
<br>
</div>ARM and x86_64 aren't going anywhere and it's too late for trap on<br>
overflow to be part of the baseline instruction set. It's far from a<br>
sure thing that it would even be added. The small x86_64 instructions<br>
are all used up so it's impossible to add trap on overflow without more<br>
expensive instruction decoding and bloated code size.<br></blockquote><div><br></div></div><div>I am sure they will figure out a way if this feature becomes a competitive advantage.  Whether this will be by adding a prefix to existing instructions, or by creating a new CPU mode I don't know.   One thing Intel could do rather easily, would be to spruce up the INTO instruction, which is currently neglected and slow because noone's using it.   It's a chicken and egg problem: why would they invest time into improving a feature that nobody can take advantage of?<br>

<br></div><div>If Wikipedia is to be believed, MIPS already has ints with overflow checking.  Some <a href="http://millcomputing.com/docs/" target="_blank">brand-new architectures</a> are heading this way too.<br></div><div>
</div><br><div>
And, as I said, if it's too slow, overflow check will be elided in optimized builds. <br>We should, however, invent a way to harass developers who overflow their ints,- to provide an incentive to think about which kind of int is needed.<br>

</div><div class=""><div></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Anyway, trapping would *not* map to how Rust currently deals with logic<br>
errors. It would need to give up on unwinding for logic errors in order<br>
to leverage these kinds of instructions. The alternative is depending on<br>
asynchronous unwinding support and OS-specific handling for the trapping<br>
instructions (SIGFPE like division by zero?).<br>
<br>
Processors already implement a trap on division by zero but Rust is<br>
currently not able to take advantage of it... until we're doing it for<br>
division, there's no indication that we'll be able to do it for other<br>
operations.<br></blockquote><div><br></div></div><div>Since division overflow already needs to be dealt with, I don't see a problem with making addition overflow do the same thing.<br><br></div><div></div><div>Eventually it might be useful to have a third kind of ints, that return Option<TResult>, however until Rust has support for monads, I don't think these would be very useful.  Intrinsic functions would probably be enough for now.<br>


</div><div class=""><div><br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
> 1. Declare that regular int types (i8, u8, i32, u32, ...) are<br>
> non-wrapping.<br>
> Check them for overflow in debug builds, maybe even in optimized builds<br>
> on platforms where the overhead is not too egregious.  There should<br>
> probably be a per-module performance escape hatch that disables overflow<br>
> checks in optimized builds on all platforms.  On zero-cost overflow<br>
> checking platforms, the checks would of course always be on.<br>
> Also, since we are saving LLVM IR in rlibs for LTO, it may even be<br>
> possible to make this a global (i.e. not just for the current crate)<br>
> compile-time decision.<br>
<br>
</div>If they're not defined as wrapping on overflow, how *are* they defined?<br>
<br>
It does have to be defined as something, even if that means an arbitrary<br>
result left up to the implementation. The result must be consistent<br>
between reads to maintain memory safety.<br></blockquote><div><br></div></div><div>In checked builds they'll trap, just like division by zero.  In unchecked builds, the result is "undefined".   But, of course, in practice, they will just wrap around.<br>


</div><div><br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">> 2. Introduce new wrapping counterparts of the above for cases when<br><div><div>


> wrapping is actually desired.<br>
><br>
> If we don't do this now, it will be much more painful later, when large<br>
> body of Rust code will have been written that does not make the<br>
> distinction between wrapping and non-wrapping ints.<br>
><br>
> Vadim<br>
<br>
</div></div><br></div><div class="">_______________________________________________<br>
Rust-dev mailing list<br>
<a href="mailto:Rust-dev@mozilla.org" target="_blank">Rust-dev@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/rust-dev" target="_blank">https://mail.mozilla.org/listinfo/rust-dev</a><br>
<br></div></blockquote></div><br></div></div>
<br>_______________________________________________<br>
Rust-dev mailing list<br>
<a href="mailto:Rust-dev@mozilla.org">Rust-dev@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/rust-dev" target="_blank">https://mail.mozilla.org/listinfo/rust-dev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br>   Jerry
</div>