[rust-dev] Integer overflow, round -2147483648

Daniel Micay danielmicay at gmail.com
Mon Jun 23 23:02:36 PDT 2014


On 24/06/14 01:55 AM, Jerry Morrison wrote:
> 
> 
> On Mon, Jun 23, 2014 at 10:32 PM, Daniel Micay <danielmicay at gmail.com
> <mailto:danielmicay at gmail.com>> wrote:
> 
>     On 24/06/14 01:17 AM, Jerry Morrison wrote:
>     >
>     > Does `checked { }` mean all functions within that scope use
>     > checked-integer arithmetic? This sounds great to me.
> 
>     It would only apply to local operations. It's not possible to alter the
>     behaviour of functions in general because of crates. It would also be
>     incorrect if they required wrapping semantics.
> 
>     > One detail: There should be a way to explicitly specify
>     > wraparound-arithmetic, e.g. wraparound-arithmetic operators. Lint
>     would
>     > never complain about that.
> 
>     I think the scope-based solution would probably be cleaner in that case:
> 
>     #[checked]
>     fn foo() { ... }
> 
>     #[unchecked]
>     fn bar() { #[checked] { ... }  }
> 
>     The lint would warn for operations in a scope without an explicit
>     decision one way or the other. You could even put `#[checked]` at module
>     / crate level and override it in inner scopes.
> 
>     I think that's as a sane solution, as opposed to introducing dialects
>     with compiler switches which I really dislike.
> 
> 
> Attributes do seem saner than compiler switches.
> 
> Intentional-wraparound arithmetic is different than
> unchecked-for-speed-and-lint-could-complain, and probably only applies
> to fixed sized, unsigned integers. Would you use wraparound operators
> like &+ for those?

Well, perhaps a better naming convention is `#[wrapping(no)]` (with
checks) and `#[wrapping(yes)]`. I don't really like the idea of having
language support for a no-op convention.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140624/d68e3cb5/attachment.sig>


More information about the Rust-dev mailing list