[rust-dev] Integer overflow, round -2147483648

Jerry Morrison jhm456 at gmail.com
Tue Jun 24 17:48:54 PDT 2014


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?

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.
>
>


-- 
   Jerry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140624/d49e1043/attachment.html>


More information about the Rust-dev mailing list