On Mon, Apr 29, 2013 at 6:33 PM, Jack Moffitt <[email protected]> wrote:
> > As was pointed out earlier with Mozilla source code, integer overflows > > "do not happen". Probably because, in security-conscious code, you are > > supposed to validate your inputs for your actual expected range, and > > when you do, built-in overflow checks are just unnecessary overhead. > > If you're referring to Robert's comments, then I read them exactly the > opposite way. He did mention that overflow to BigInts wasn't needed, > but he is on the wants checked math side. > > I agree that this is a tradeoff, and that there is probably some > performance loss at which it doesn't make sense. Until we have data on > how expensive such a feature is, we can't make much progress in that > particular debate. I just wanted to note my preference for having it > default to on if it didn't cost too much, whatever "cost too much" > might mean :) > > jack. > _______________________________________________ > Rust-dev mailing list > [email protected] > https://mail.mozilla.org/listinfo/rust-dev > It might be interesting to check how Clang integrated UBSan and its performance implications. I know there was some work using "cold" functions and "expect" hints to teach LLVM than the "undefined" branch (and callback) were to be very rare so that it could optimize the code taking them out of the hot path. You can check a blog article on usage of UBSan here [1], and rebound to the User's Manual from there; might be interesting to benchmark the code produced by Clang with/without integer overflow detection (and just that, UBSan include many other validations) to see what LLVM can do with it. [1]: http://blog.llvm.org/2013/04/testing-libc-with-fsanitizeundefined.html -- Matthieu
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
