[rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0

Owen Shepherd owen.shepherd at e43.eu
Sun Jan 12 05:34:32 PST 2014

On 12 January 2014 13:23, james <james at mansionfamily.plus.com> wrote:

> On 11/01/2014 22:38, Owen Shepherd wrote:
>> I agree, however, I feel that the names like "i32" and "u32" should be
>> trap-on-overflow types. The non overflow ones should be "i32w" (wrapping)
>> or similar.
>> Why? Because I expect that otherwise people will default to the wrapping
>> types. Less typing. "It'll never be a security issue", or "Looks safe to
>> me", etc, etc. Secure by default is a good thing, IMO
> I don't think making 'i32' have different semantics by default from
> int32_t (or from the 'i32' typedef most of us will have used for years) is
> a good idea in a wannabe systems programming language.  It is too
> surprising.
> There might be a good case for having a pragma control some 'check for
> overflow' in a paranoid test mode, but i think that most programmers, most
> of the time, will expect 2s complement arithmetic 'as usual'.

Signd integers have no defined behavior on overflow in C or C++.

Go on, compile this program with optimizations enabled:

#include <stdio.h>
#include <limits.h>

int main() {
    for(int i = INT_MAX; i > 0; i++) {

Watch it loop endlessly, because since UB is undefined, the compiler
assumes it never occurs, and therefore i will always be greater than 0
since it starts higher.

I think defined behavior by default is better than undefined behavior, and
I also think that overflow detection by default is better than random
wrapping by default.

There are applications where wrapping is useful, or where checking for
overflow is too expensive. For those, unchecked integers should be only a
short distance away.

But I also feel that by making the unchecked ones the shorter name, the
language would be implicitly sending a message that they're preferred.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140112/af8c7015/attachment.html>

More information about the Rust-dev mailing list