clarify extreme operator behaviour

[Gankro]

This is just clarifying things which were agreed on in various places but poorly specified.

rendered draft

[eddyb]

Maybe division and remainder by 0 are "nonsensical", but INT_MIN / -1 is an overflow, the same way -INT_MIN is (which isn't caught, not even in a debug build).

[nagisa]

rust-lang/rust#24500 and rust-lang/rust#23154 and rust-lang/rust#22020 all seem to involve unary negation checking for overflow, but in practice this seems to be not working indeed in the context of const-eval.

[eddyb]

-std::i32::MIN does give a const-eval error, but let m = std::i32::MIN; -m doesn't (so there's no runtime checking).

[nagisa]

Seems to work for me.

[eddyb]

Oops, I used playbot - does it run in release mode?

[17:13] <eddyb> playbot: let x = std::i32::MIN; -x
[17:13] [Notice] -playbot to #rust-internals- -2147483648

[nikomatsakis]

Regarding -INT_MIN and INT_MIN/-1 -- for whatever reason, division had code to check and panic, but multiplication did two's complement wrapping. We have preserved that behavior, afaik, inconsistent or not, and hence these edits correctly describe the current situation.

[eddyb]

What is "this", that is prevented here?

[nikomatsakis]

@eddyb

What is "this", that is prevented here?

The undefined behavior that results from an overlong shift, presumably.

[eddyb]

Yes, that's what I assume it means, but there's no description of that undefined behavior which "this" could refer to.

[Gankro]

Strictly speaking at this level Undefined Behaviour in LLVM in not an object -- this is Rust's semantics. Will clarify.

[nagisa]

Do we guarantee this for platforms where arithmetic is not two’s complement?

[eddyb]

I don't think LLVM supports anything other than two's complement.

[Gankro]

Yeah. We also don't acknowledged floating point rounding modes for similar reasons.

[oli-obk]

actually this is currently only the behavior when the operation cannot be constant evaluated. Even with checking disabled, const evaluatable cases will cause a compiler error. see #1229 for discussion

[Gankro]

Clarified.

[nikomatsakis]

seems fine, but it may be worth nothing that this is the behavior that the X86 does (and Java, as well, not coincidentally I think)

[nikomatsakis]

Similarly, the reason here is that LLVM's sdiv instruction makes those two cases undefined behavior: "Division by zero leads to undefined behavior. Overflow also leads to undefined behavior; this is a rare case, but can occur, for example, by doing a 32-bit division of -2147483648 by -1." I don't believe there is a version of div where they are defined behavior. We could, of course, opt to do the "overflow" for -1 ourselves. Division by zero OTOH has traditionally been a fault in many CPUs and programming languages.

[glaebhoerl]

As @bill-myers originally pointed out here INT_MIN % -1 is mathematically well-defined to be 0.

[nikomatsakis]

Hear ye, hear ye. This RFC is entering final comment period.

[nikomatsakis]

@glaebhoerl true. I guess we could consider altering the behavior, but I think this RFC is basically aiming at documenting existing behavior, and that particular result is long-standing.

[glaebhoerl]

@nikomatsakis Then shall I open a separate issue to keep track of that possibility?

[nikomatsakis]

On Sat, Sep 05, 2015 at 01:53:14AM -0700, Gábor Lehel wrote:

@nikomatsakis Then shall I open a separate issue to keep track of that possibility?

Sure.

[nikomatsakis]

Huzzah! The language design team has decided to accept this RFC.