feat: checks on upper bounds of contract storage sizes #169
Conversation
TilakMaddy
changed the title
TilakMaddy
changed the title
|
@DaniPopes I have also added a test case to demonstrate what happens when more than 2^256 - 1 storage slots are requested. |
crates/sema/src/typeck/mod.rs
Outdated
| let mut total_size = U256::from(1); | ||
| for field_id in strukt.fields { | ||
| let variable = gcx.hir.variable(*field_id); | ||
| let t = gcx.type_of_hir_ty(&variable.ty); |
There was a problem hiding this comment.
please don't use type_of_hir_ty since it recomputes the type which is already computed for the variable; instead use type_of_item and struct_field_types, and also you have to check for recursive struct so as to not recurse infinitely with struct_recursiveness
applies above in check_storage_size_upper_bound too
There was a problem hiding this comment.
@DaniPopes I have applied the suggestion and got the tests passing but I have 2 doubts
-
Why check again for struct recursiveness when it's already done here ? Also I'm not sure where to add the logic
-
Why does doing
gcx.type_of_itemwrap all the contract's elementary-type-storage-variables inRef(.., DataLocation::Storage)? Is it by design or bug? Because technically there could be "references" to "storage variables" used within functions that which does NOT make them the storage variables themseleves?
[Given gcx.type_of_hir_ty(..) doesn't do this "wrapping"] So they are not quite interchangeable 🤔 . . .
https://github.com/ethereum/solidity/blob/03e2739809769ae0c8d236a883aadc900da60536/libsolidity/analysis/ContractLevelChecker.cpp#L556C1-L570C2