[rust-dev] Integer overflow, round -2147483648

Florian Zeitz florob at babelmonkeys.de
Sun Jun 22 09:06:37 PDT 2014


On 22.06.2014 17:32, Benjamin Striegel 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?
> 

This is such a terrible straw-man argument, and I hate hearing it over
and over again. Most of all because it sounds really hostile to me: "Go
away, your problem doesn't require ultimate performance, this is not the
language you should be using".
And in the spirit of sending I-messages: I feel like I'm being told to
stop using the language. That feels a bit unproductive to me.
It also fuels the flame of people insisting bound checks should be optional.

To me the point of this discussion boils down to this:
I think we can all agree that having checked arithmetic is worthwhile.
Rust already has it as e.g. `.checked_add()'.
I think it might even be non-controversial that it is worthwhile to make
using them more ergonomic. Either by providing a separate operator, or a
separate type (I personally think the later option fits the language
better, but YMMV).

What is apparently reason for a heated debate is, whether this should be
the default. That certainly is a safety vs. performance debate.

It has been pointed out that checked arithmetic actually impacts
performance beyond introducing a jump instruction, after each add.
It causes a lot of optimization to be disabled/ineffective.

I have however not seen strong arguments that the issues imposed by not
always using checked arithmetic are generally security critical.

I'd welcome a civil, rational discussion of the costs and benefits of
each approach, instead of whatever this is currently starting to turn into.

Regards,
Florian


More information about the Rust-dev mailing list