[rust-dev] Integer overflow, round -2147483648

Evan G eg1290 at gmail.com
Sun Jun 22 08:39:47 PDT 2014


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/84d42c7f/attachment.html>


More information about the Rust-dev mailing list