[rust-dev] Integer overflow, round -2147483648

Daniel Micay danielmicay at gmail.com
Mon Jun 23 22:00:15 PDT 2014

On 23/06/14 11:58 PM, François-Xavier Bourlet wrote:
> In short:
>  - everybody wants checked integer arithmetic because it helps to
> write better code (thanks to compile time and runtime errors)
>  - nobody wants to pay the price in performances, but maybe in the
> future, hardware++ will make it easier... or so on...
> What about:
>  - Defining "safe" integer in Rust with strict and well defined rules.
>  - Enforcing the rules is an incremental process.
> At first, Rust will not enforce any rules, maybe in debug mode or what
> not for who wants to pay the cost. One could add an attribute on
> blocks to enforce runtime overflow check at all cost, when you really,
> really need safety no matter the speed tradeoff. And in the future,
> the compiler & standard library are free to effectively enforce more
> of the rules, as performances tradeoff mitigate.
> Its kinda like when C/C++ compiler started warning that not all cases
> where handled in switch/cases on enums (yes I know our case is
> different on many level).
> What is important, is that the rules of the different safe integer
> types are well defined, even if not necessarily enforced yet.
> If you think about it, its better than nothing.
> The goal is not to solve everything right now, but at least to define
> the scope of the problem when it is still possible, before everybody
> uses "unsafe integers", so it can be implemented in the future.

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.

Simply making it unspecified makes 0% of the operations checked because
few people will ever pay the huge performance cost to enable them, while
adding usable checked arithmetic would actually be valuable.

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's introducing unspecified behehaviour / language
dialects, the problems associated with fragmenting code into various
integer types, and the other issues that were raised. This seems
strictly worse than an operator or scope-based solution to me.

Increasing the complexity of the language with no clear goals is not
"better than nothing". It's not somehow going to become 'free' in the
near future, and there's no point in trying to design for 25 years down
the road at the expense of making it worse today.

-------------- 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/47f72bda/attachment.sig>

More information about the Rust-dev mailing list