On Mon, Jun 23, 2014 at 1:49 PM, Daniel Micay <danielmi...@gmail.com> wrote:
> 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.
>
Does `checked { }` mean all functions within that scope use
checked-integer arithmetic? This sounds great to me.
One detail: There should be a way to explicitly specify
wraparound-arithmetic, e.g. wraparound-arithmetic operators. Lint would
never complain about that.
> 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%.
>
>
> _______________________________________________
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>
>
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
