On 23/06/14 04:00 PM, Gregory Maxwell wrote: > On Mon, Jun 23, 2014 at 12:50 PM, Daniel Micay <danielmi...@gmail.com> wrote: >> The discussion here is about checking for both signed / unsigned integer >> overflow, as in passing both `-fsanitize=signed-integer-overflow` and >> `-fsanitize=unsigned-integer-overflow`. Rust has defined signed overflow >> already so it doesn't make sense to just check for that. > > The undefinedness of just signed overflow in C has shown itself to be > useful from a performance perspective and, paradoxically now that > better testing tools exist, from a correctness perspective.
I already mentioned the issue of undefined overflow, and how using
inbounds pointer arithmetic is both higher-level (iterators) and just as
fast. It doesn't cover every case, but it covers enough of them that the
use case for undefined signed overflow is reasonable small.
Undefined behaviour on overflow is also a memory safety issue, while
wrapping on overflow is not. You can claim that it could cause memory
safety issues via incorrect unsafe code, but low-level code is going to
be using wrapping or undefined semantics for performance regardless of
the default.
> I think a lot the discussion here has been about having checked types
> and making them a default, not in forcing all possible usage into
> them. If only making the signed type checked had much better
> performance characteristics then it ought to be considered.
Slower performance than Java by default would kill off nearly all
interest in Rust, and would make the claim that it's a viable C
replacement even less true than it already is.
I don't understand what the problem would be with my proposal to have
either `checked { }` or checked operators + a lint for unchecked usage.
> John was kind enough to post numbers for each of many microbenchmarks
> instead of a range. Beyond the signed vs signed+unsigned do you have
> any additional idea why his numbers would be lower than yours?
If you read my response, you'll see that I mentioned the impact of the
architecture on the results. I also mentioned that the code bloat issue
does not impact microbenchmarks as they fit entirely into the L1 cache
with or without the overflow checks. If we're going to play the game of
picking and choosing benchmarks, I can demonstrate cases where the
overhead is 1000-2000%.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
