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
The "unchecked" arithmatic methods on the Address trait were documented
to cause undefined behavior in the case of overflow or underflow. This
is a strange claim; if that were truly the case, the methods should have
been unsafe. It wasn't, though; every existing implementation of the
trait used the impl_address_ops! macro, which just implements them with
the standard Rust arithmatic operators, which follow this well-defined
behavior:
- In debug mode, overflow is checked for and results in a panic.
- In release mode, overflow results in silent wrapping.
The wrapping behavior may be surprising or result in incorrect behavior,
but it isn't undefined - we know exactly what will happen, and the
optimizer is required to preserve that - so we shouldn't call it
undefined.
It's also worth nothing that the names of these methods are a little
confusing - the integer types in std have unchecked_* methods that
actually invoke UB on overflow (and, accordingly, are unsafe). It might
be worth renaming these methods to something more consistent with std's
naming. This is slightly complicated by the fact that std doesn't
actually have a name for this behavior; it's just what the unqualified +
operator or .add() method does. We may not want that, though, if we're
trying to be more careful about overflow.
In any case, we don't have to know how it should work to document the
current behavior.
Signed-off-by: Gaelan Steele <[email protected]>
0 commit comments