[rust-dev] Integer overflow, round -2147483648

Benjamin Striegel ben.striegel at gmail.com
Sun Jun 22 09:00:34 PDT 2014


> There are plenty of other features to Rust then "absolute speed".

You're right. Here are the three primary features of Rust, in decreasing
order of importance:

    1. Memory safety
    2. C++ performance
    3. Safe concurrency

Notably, correctness in the face of integer overflow is merely a
nice-to-have, and if it would compromise the second principle then we
cannot accept it. The only features that are allowed to compromise
performance are those that are required to satisfy memory safety, and the
developers have already concluded that defined integer overflow does not
jeopardize memory safety. Your only recourse is to convince the developers
that they are incorrect and that overflow semantics are in fact a memory
safety hazard. Railing against the incorrectness of overflow semantics
alone isn't going to sway anyone.


On Sun, Jun 22, 2014 at 11:39 AM, Evan G <eg1290 at gmail.com> wrote:

> Because of memory safety? Because you want low-level control without
> absolute speed? Because of a small memory footprint? Because of having a
> good async story without giving up a lot of speed?
>
>  There are plenty of other features to Rust then "absolute speed". Just
> because that's *your* usecase for it doesn't mean you should force it on
> others.
>
>
> On Sun, Jun 22, 2014 at 10:32 AM, Benjamin Striegel <
> ben.striegel at gmail.com> wrote:
>
>> > 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
>>
>> This is a mistaken assumption. Systems programming exists on the extreme
>> end of the programming spectrum where edge cases are the norm, not the
>> exception, and where 80/20 does not apply. If you don't require absolute
>> speed, why are you using Rust?
>>
>>
>> On Sun, Jun 22, 2014 at 6:37 AM, Matthieu Monrocq <
>> matthieu.monrocq at gmail.com> wrote:
>>
>>> 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
>>>>
>>>
>>>
>>> _______________________________________________
>>> Rust-dev mailing list
>>> Rust-dev at mozilla.org
>>> https://mail.mozilla.org/listinfo/rust-dev
>>>
>>>
>>
>> _______________________________________________
>> 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/5cd655c4/attachment.html>


More information about the Rust-dev mailing list