<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div>For some applications, Rustís bounds checks and the inability of rustc to eliminate them in nontrivial cases will already be too much of a performance sacrifice. What do we say to those people? Is it just that memory safety is important because of its security implications, and other forms of program correctness are not?</div><div><br></div><div>I am wary of circling around on this topic again, but I feel that the biggest mistake in this discussion js that checked overflow in a language requires a potential trap on every single integer operation. Languages like Ada (and Swift, to a lesser extent), allow for slightly imprecise exceptions in the case of integer overflow.</div><div><br></div><div>A fairly simple rule is that a check for overflow only needs to occur before the incorrect result may have externally visible side effects. Adaís rule even lets you go a step further and remove overflow checks from loops  in some cases (without violating control dependence of the eventual overflowing operation).</div><div><br></div><div>One model like this that has been proposed for C/C++ is the ďAs Infinitely RangedĒ model (see <a href="http://www.cert.org/secure-coding/tools/air-integer-model.cfm">http://www.cert.org/secure-coding/tools/air-integer-model.cfm</a>), where operations either give the result that would be correct if integers had infinite precision, or cause a trap. This allows for more optimizations to be performed, and although it is questionable to me whether they preserved control dependence of overflow behavior in all cases, they report a 5.5% slowdown on SPEC2006 with GCC 4.5 (compared to a 13% slowdown with more plentiful checks) using a very naive implementation. A lot of those checks in SPEC2006 could probably just be eliminated if the language itself distinguished between overflow-trapping and overflow-permissive operations. If a compiler optimizer understood the semantics of potentially trapping integer operations better (or at all), it could reduce the overhead of the checks.</div><div><br></div><div>I know that some people donít want to require new compiler techniques (or are afraid of relying on something outside of the scope of what LLVM can handle today), but it would be unfortunate for Rust to make the wrong decision here based on such incidental details rather than what is actually possible.</div><div><br></div><div>Cameron</div><div><br></div><div><div>On Jun 22, 2014, at 9:21 AM, Benjamin Striegel <<a href="mailto:ben.striegel@gmail.com">ben.striegel@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr">I apologize for being hostile. As Florian has noted, we're just arguing about the default behavior here. It is my opinion that checked behavior by default will make Rust unsuitable for filling C++'s niche, and send the message that we are not serious about performance.<br>

</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Jun 22, 2014 at 12:10 PM, Evan G <span dir="ltr"><<a href="mailto:eg1290@gmail.com" target="_blank">eg1290@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">I don't think I was ever "Railing against the incorrectness of overflow semantics"? I was just pointing out that your (imo pretty hostile?) message about "If you don't require absolute speed, why are you using Rust?" doesn't really ring true. Most C++ programmers don't even require absolute speed.<br>




</div>
</blockquote></div><br></div>
_______________________________________________<br>Rust-dev mailing list<br><a href="mailto:Rust-dev@mozilla.org">Rust-dev@mozilla.org</a><br>https://mail.mozilla.org/listinfo/rust-dev<br></blockquote></div><br></body></html>