You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, the semantics of integer overflow are well-defined in arithmetic operations, are an "undefined value" in shifts, and trigger failure in divisions.
The "undefined value" situation is quite weird – certainly it can't be undefined behaviour (otherwise, fn main() { 1u<<1000u; } would be an unsafe program), but it is not defined. The "modular arithmetic" definition of integer overflow is not unsafe, but can harm program analysis. These probably need to be defined before 1.0.
First, intrinsics should be provided for undefined semantics, and for wrapping semantics in case of arithmetic operations. This will allow code that explicitly wants some semantics (e.g. crypto code) to use them via an explicit newtype and impl.
Second, there needs to be a proper decision involving the built-in shift operators (personally, I prefer (a : uN)<<b to be intrinsics::uN_unchecked_shift_right(a, b&((1<<N)-1)) etc. - it's zero-cost on constants, the default on x86, and quite fast on variable-length shifts on other architectures, but this can be discussed).
The text was updated successfully, but these errors were encountered:
Currently, the semantics of integer overflow are well-defined in arithmetic operations, are an "undefined value" in shifts, and trigger failure in divisions.
The "undefined value" situation is quite weird – certainly it can't be undefined behaviour (otherwise,
fn main() { 1u<<1000u; }
would be an unsafe program), but it is not defined. The "modular arithmetic" definition of integer overflow is not unsafe, but can harm program analysis. These probably need to be defined before 1.0.First, intrinsics should be provided for undefined semantics, and for wrapping semantics in case of arithmetic operations. This will allow code that explicitly wants some semantics (e.g. crypto code) to use them via an explicit newtype and impl.
Second, there needs to be a proper decision involving the built-in shift operators (personally, I prefer
(a : uN)<<b
to beintrinsics::uN_unchecked_shift_right(a, b&((1<<N)-1))
etc. - it's zero-cost on constants, the default on x86, and quite fast on variable-length shifts on other architectures, but this can be discussed).The text was updated successfully, but these errors were encountered: