-
Notifications
You must be signed in to change notification settings - Fork 428
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove unchecked arithmetic #1831
Conversation
@@ -267,7 +267,10 @@ mod erc1155 { | |||
|
|||
// Given that TokenId is a `u128` the likelihood of this overflowing is pretty | |||
// slim. | |||
self.token_id_nonce += 1; | |||
#[allow(clippy::arithmetic_side_effects)] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not fun of a this. Is there a reason we can't do checked arithmetic operation here? If the operation is not implemented for the type, then we need to implement it first before introducing the change here and in cargo contract.
Otherwise we are breaking the arithmetic safety guarantees.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can. But it is not necessary here. Overflowing a u128 is impossible by incrementing by 1 per extrinsic.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do I understand correctly that we won't be able to use arithmetic operators (i.e. +
, -
, /
, *
) on numbers at all? I am just thinking of what impact it will have on the developer experience if we have to tell everyone knows that they need to use checked_
operations specifically.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do I understand correctly that we won't be able to use arithmetic operators (i.e. +, -, /, *) on numbers at all?
Correct.
I am just thinking of what impact it will have on the developer experience if we have to tell everyone knows that they need to use checked_ operations specifically.
Or saturating
or wrapping
. Developers should express the overflow behaviour in-code instead of leaving it open to a compile time switch. We should have done that from the beginning. People have to think about this anyways.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Or
saturating
orwrapping
.
Or use Wrapping
and Saturating
, so then the arithmetic itself wouldn't become an unreadable soup of function calls, e.g. this compiles:
#![deny(clippy::arithmetic_side_effects)]
use core::num::Wrapping;
fn foo(a: Wrapping<u32>, b: Wrapping<u32>) -> Wrapping<u32> {
a + b
}
(Saturating
is still unstable though, but we could just provide our own wrapper for the time being.)
Should be merged before new cargo contract release or the CI will break. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can be merged now
We need to remove all unchecked arithmetic from ink! itself so our CI does not fail after use-ink/cargo-contract#1190 is merged.
I trivially transformed all unchecked arithmetic to
checked_* + unwrap
which preserves the current behaviour which was to panic on overflow but makes it explicit. I had to inline thearrayref
macro so that I were able to remove the unchecked arithmetic from it.