[rust-dev] Integer overflow, round -2147483648

Vadim Chugunov vadimcn at gmail.com
Tue Jun 24 18:06:04 PDT 2014

On Tue, Jun 24, 2014 at 5:48 PM, Jerry Morrison <jhm456 at gmail.com> wrote:

> Yeah. And would programmers also have to convert each literal, like in the
> Java-ish hashCode() example:
> result = (wint) 31 * result + (wint) areaCode;
> because adding a non-wraparound integer and a wraparound integer is
> ambiguous?

Literal type could be inferred, just like it is inferred now for regular

> Hey, it's "just" 5 more arithmetic operators. (A building architect once
> said, "'Just' is a 4-letter word.")
> On Tue, Jun 24, 2014 at 5:41 PM, Daniel Micay <danielmicay at gmail.com>
> wrote:
>> On 24/06/14 08:39 PM, Vadim Chugunov wrote:
>> > I mostly agree, though  for #1, I think that new int types would be more
>> > appropriate.   A set of special operators seems like an overkill for a
>> > relatively infrequently used functionality.  Annotations are too broad
>> > (what if I need to do both wrapping and non-wrapping calculations in the
>> > same scope?).
>> Introducing new types would make the language more painful to use, and
>> it would be difficult to determine the correct types to use at API
>> boundaries. It would be a large backwards compatibility hazard among
>> other issues, and would introduce performance overhead due to issues
>> like `&[u32]` and `&[u32c]` being different types.
Easy: don't use normal ints in the API, Cast to wrapping ints when
needed.    I don't expect the slice scenario to come up often, but if it
does, these slice types can be transmuted into each other.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140624/7c4f1382/attachment.html>

More information about the Rust-dev mailing list