Investigate overflow scenarios
Clarification and motivation
Here is a list of possible errors in RPC: http://tezos.gitlab.io/api/errors.html#michelson-parsing-macros
Pay attention to timestamp_add
and timestamp_sub
. Apparently overflow/underflow can happen in arithmetic instructions involving timestamps, but I couldn't see such cases in our code and I couldn't produce such errors using tezos-client
.
Acceptance criteria
- Figure out in which cases
timestamp_add
andtimestamp_sub
errors can occur. You may have to check OCaml code or ask Tezos devs. - If they can occur during smart contract interpretation, make sure our interpreter reports these errors in the respective cases. Add tests for these cases.
Optional part
We have
-- | Denotes the error type occured in the arithmetic operation.
data ArithErrorType
= AddOverflow
| MulOverflow
| SubUnderflow
| LslOverflow
| LsrUnderflow
deriving stock (Show, Eq, Ord, Generic)
-- | Represents an arithmetic error of the operation.
data ArithError n m
= MutezArithError ArithErrorType n m
| ShiftArithError ArithErrorType n m
deriving stock (Show, Eq, Ord, Generic)
LslOverflow
and LsrUnderflow
can only happen in ShiftArithError
and the other three can only be part of MutezArithError
. But it's not reflected in type. I slightly dislike it. Some ideas I have:
- Turn
ArithErrorType
into two types. - Remove
ArithErrorType
and how 5 constructors inArithError
.
Apart from that I see that ArithError
has n
and m
parameters which are always Value TMutez
in MutezArithError
and Value TNat
in ShiftArithError
. I am not sure it's a problem, but maybe it can be refactored somehow to make it clearer that MutezArithError
can store only mutezes.