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
We need to have a more principled approach to generate arithmetic bounds for storage variables.
Right now:
inRange assertions in preconditions might generate duplicate bounds assertions as Enrich already adds some go them
inRange assertion can be implicit and generated automatically using type information, though we need to be careful to with the semantics of this. For example for a storage variable uint128 x , writing the following update x => (x + 1234) + 5678
will implicitly add the precondition inRange(uint128, (x + 1234) + 5678) which implies that every subexpression never goes out of uint128 bound.
Issue #109 describes how an inferring-bounds analysis can be performed.
The text was updated successfully, but these errors were encountered:
zoep
changed the title
Unify the approach of integer bound assertions
Unify the approach of integer bounds assertions
Nov 3, 2023
We need to have a more principled approach to generate arithmetic bounds for storage variables.
Right now:
inRange
assertions in preconditions might generate duplicate bounds assertions as Enrich already adds some go theminRange
assertion can be implicit and generated automatically using type information, though we need to be careful to with the semantics of this. For example for a storage variableuint128 x
, writing the following updatex => (x + 1234) + 5678
will implicitly add the precondition
inRange(uint128, (x + 1234) + 5678)
which implies that every subexpression never goes out ofuint128
bound.Issue #109 describes how an inferring-bounds analysis can be performed.
The text was updated successfully, but these errors were encountered: