<div dir="ltr"><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Jun 23, 2014 at 1:49 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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">On 23/06/14 04:00 PM, Gregory Maxwell wrote:<br>
> On Mon, Jun 23, 2014 at 12:50 PM, Daniel Micay <<a href="mailto:danielmicay@gmail.com">danielmicay@gmail.com</a>> wrote:<br>
>> The discussion here is about checking for both signed / unsigned integer<br>
>> overflow, as in passing both `-fsanitize=signed-integer-overflow` and<br>
>> `-fsanitize=unsigned-integer-overflow`. Rust has defined signed overflow<br>
>> already so it doesn't make sense to just check for that.<br>
><br>
> The undefinedness of just signed overflow in C has shown itself to be<br>
> useful from a performance perspective and, paradoxically now that<br>
> better testing tools exist, from a correctness perspective.<br>
<br>
I already mentioned the issue of undefined overflow, and how using<br>
inbounds pointer arithmetic is both higher-level (iterators) and just as<br>
fast. It doesn't cover every case, but it covers enough of them that the<br>
use case for undefined signed overflow is reasonable small.<br>
<br>
Undefined behaviour on overflow is also a memory safety issue, while<br>
wrapping on overflow is not. You can claim that it could cause memory<br>
safety issues via incorrect unsafe code, but low-level code is going to<br>
be using wrapping or undefined semantics for performance regardless of<br>
the default.<br>
<br>
> I think a lot the discussion here has been about having checked types<br>
> and making them a default, not in forcing all possible usage into<br>
> them.  If only making the signed type checked had much better<br>
> performance characteristics  then it ought to be considered.<br>
<br>
Slower performance than Java by default would kill off nearly all<br>
interest in Rust, and would make the claim that it's a viable C<br>
replacement even less true than it already is.<br>
<br>
I don't understand what the problem would be with my proposal to have<br>
either `checked { }` or checked operators + a lint for unchecked usage.<br></blockquote><div><br></div><div>Does `checked { }` mean all functions within that scope use checked-integer arithmetic? This sounds great to me.</div>
<div><br></div><div>One detail: There should be a way to explicitly specify wraparound-arithmetic, e.g. wraparound-arithmetic operators. Lint would never complain about that.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
> John was kind enough to post numbers for each of many microbenchmarks<br>
> instead of a range. Beyond the signed vs signed+unsigned do you have<br>
> any additional idea why his numbers would be lower than yours?<br>
<br>
If you read my response, you'll see that I mentioned the impact of the<br>
architecture on the results. I also mentioned that the code bloat issue<br>
does not impact microbenchmarks as they fit entirely into the L1 cache<br>
with or without the overflow checks. If we're going to play the game of<br>
picking and choosing benchmarks, I can demonstrate cases where the<br>
overhead is 1000-2000%.<br>
<br>
<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></div></div>