[rust-dev] Integer overflow, round -2147483648

Matthieu Monrocq matthieu.monrocq at gmail.com
Sun Jun 22 03:37:38 PDT 2014


I am not a fan of having wrap-around and non-wrap-around types, because
whether you use wrap-around arithmetic or not is, in the end, an
implementation detail, and having to switch types left and right whenever
going from one mode to the other is going to be a lot of boilerplate.

Instead, why not take the same road than swift and map +, -, * and / to
non-wrap-around operators and declare new (more verbose) operators for the
rare case where performance matters or wrap-around is the right semantics ?

Even though Rust is a performance conscious language (since it aims at
displacing C and C++), the 80/20 rule still applies and most of Rust code
should not require absolute speed; so let's make it convenient to write
safe code and prevent newcomers from shooting themselves in the foot by
providing safety by default, and for those who profiled their applications
or are writing hashing algorithms *also* provide the necessary escape
hatches.

This way we can have our cake and eat it too... or am I missing something ?

-- Matthieu



On Sun, Jun 22, 2014 at 5:45 AM, comex <comexk at gmail.com> wrote:

> On Sat, Jun 21, 2014 at 7:10 PM, Daniel Micay <danielmicay at gmail.com>
> wrote:
> >> Er... since when?  Many single-byte opcodes in x86-64 corresponding to
> >> deprecated x86 instructions are currently undefined.
> >
> > http://ref.x86asm.net/coder64.html
> >
> > I don't see enough gaps here for the necessary instructions.
>
> You can see a significant number of invalid one-byte entries, 06, 07,
> 0e, 1e, 1f, etc.  The simplest addition would just be to resurrect
> INTO and make it efficient - assuming signed 64 and 32 bit integers
> are good enough for most use cases.  Alternatively, it could be two
> one-byte instructions to add an unsigned version (perhaps a waste of
> precious slots) or a two-byte instruction which could perhaps allow
> trapping on any condition.  Am I missing something?
> _______________________________________________
> Rust-dev mailing list
> Rust-dev at mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140622/1d782d3b/attachment.html>


More information about the Rust-dev mailing list