[rust-dev] Integer overflow, round -2147483648

Daniel Micay danielmicay at gmail.com
Tue Jun 24 11:39:15 PDT 2014

On 24/06/14 11:12 AM, Gregory Maxwell wrote:
> On Mon, Jun 23, 2014 at 10:00 PM, Daniel Micay <danielmicay at gmail.com> wrote:
>> I don't understand why this would be better than either `checked {}` or
>> checked operators along with an opt-in lint to catch unchecked
>> operators. It's far better than simply saying stuff is unspecified and
>> not actually attempting to tackle the problem. If you can't depend on
>> the semantics then there's no reason to have the feature.
> Because there are many places where the runtime cost is unacceptable—
> as you've pointed out yourself. But running tests and debug builds
> with that cost is seldom an unacceptable hit and can improve code
> quality a lot, plus static analysis can make use of the additional
> information.  But all of this is unworkable if the code is full of
> harmless overflows because overflow was a perfectly acceptable thing
> to do in all cases.
> The behavior of non-checked non-wrapping types could be specified
> in-so-far as they _either_ wrap or fault, up to the implementation...
> and a checked{} block could force the latter.

A language full of implementation defined behaviour and language
dialects via compiler switches has no place in 2014.

A top-level `#![checked]` flag with the ability to turn it off in
performance critical scopes will work fine if the claims about compiler
optimization passes here are true. I don't see a reason to have a
compiler switch when most of the people who want this feature are so
certain that it can be made cheap.

>> Simply making it unspecified makes 0% of the operations checked because
> few people will ever pay the huge performance cost to enable them,
> I would expect that virtually everyone would run enable them in
> testing/QA builds, and all static analysis tools would make use of the
> additional information (e.g. that if it can prove that some series of
> operations will cause an overflow, thats a bug).
>> This proposal is just the same stuff that has already been proposed
> without any response to most of the issues raised by those on the other
> side of the fence
> It seemed pretty clear to me that he was attempting to try to balance
> the concerns. Perhaps he failed, but you spent half your message
> dismissing his attempted compromises before saying he made none at
> all.

He wasn't trying to balance the concerns, he was presenting the same
proposal yet again and not addressing the concerns that have been
raised. There were no attempts at compromising, it's the same thing as
the other proposals but presented as if it's a compromise.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140624/d7065e7e/attachment.sig>

More information about the Rust-dev mailing list