[rust-dev] Integer overflow, round -2147483648

Gregory Maxwell gmaxwell at gmail.com
Tue Jun 24 08:12:59 PDT 2014

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.

> 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

More information about the Rust-dev mailing list