Niv/fix sanity failure #183
Conversation
nivcertora
requested review from
nd-certora and
yoav-el-certora
and removed request for
liav-certora
| // invariant version is getting SANITY_FAILURE using the below rule instead | ||
| // invariant lockStatusDontChange() | ||
| // !contract_lock_status; |
There was a problem hiding this comment.
Which sanity failure did you receive on this invariant?
I couldn't find a link to a failing job here:
https://certora.atlassian.net/browse/CERT-9252
There was a problem hiding this comment.
would also like to know what was wrong with the invariant, it looks ok and we still want such invariants. do you have a link to the original spec with the sanity failures
There was a problem hiding this comment.
../repo/CVLByExample/TransientStorage/Hooks/runTransientStorage.conf
https://vaas-stg.certora.com/output/52759/0105a027db864c0bb9897978e361037d?anonymousKey=6f78ed30dd77d25d27ec6cefcbf5ad358a62efe9
| @@ -129,12 +129,6 @@ hook Sstore _customers[KEY address user].accounts.length uint256 newLength { | |||
| numOfAccounts[user] = newLength; | |||
| } | |||
|
|
|||
| /** | |||
| An internal step check to verify that our ghost works as expected, it should mirror the number of accounts. | |||
| Once the sload is defined, this invariant becomes a tautology | |||
There was a problem hiding this comment.
Once the sload is defined, this invariant becomes a tautology
Is sload now defined nowadays, so is this why we see the sanity failure for trivial post condition of the invariant?
CERT-9252 | Fix sanity failures in induction base for major version 8
| // invariant version is getting SANITY_FAILURE using the below rule instead | ||
| // invariant lockStatusDontChange() | ||
| // !contract_lock_status; |
There was a problem hiding this comment.
would also like to know what was wrong with the invariant, it looks ok and we still want such invariants. do you have a link to the original spec with the sanity failures
| @@ -1,14 +1,11 @@ | |||
| invariant isUnlocked(env e) | |||
| getLock(e) == 0; | |||
|
|
|||
There was a problem hiding this comment.
what was the sanity failure? we prefer invariant as the requireinvariant is safer
There was a problem hiding this comment.
No description provided.