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 currently only support remote reads of the mutable state of a contract, but not of the immutable state (the contract parameters).
To support this we need the following:
A syntax for contract parameters in address types. Contract parameters may have the same name as a field, so we need to be able to distinguish syntactically between a remote field and a remote contract parameter. One idea is ByStr20 with contract (x : Uint128) ... end.
A syntax for remote reads of contract parameters. One idea is x <-& c.(x).
On the C++ side, a way to fetch the value of a contract parameter. One suggestion is that we add contract parameters to the levelDB database with a suitable prefix (e.g., _cparam_<parameter name>), so that we can fetch them in the same way as we do for mutable fields, but that requires a database migration.
The text was updated successfully, but these errors were encountered:
Resolving this issue would simplify contract auditing. As of now contract writers create read-only contract fields initialized with immutable contract parameters to be able to read those. And the dead code detector reports these fields in warning which can be distracting from actual errors when the contract author forgot to put in code that updates a field.
We currently only support remote reads of the mutable state of a contract, but not of the immutable state (the contract parameters).
To support this we need the following:
ByStr20 with contract (x : Uint128) ... end
.x <-& c.(x)
._cparam_<parameter name>
), so that we can fetch them in the same way as we do for mutable fields, but that requires a database migration.The text was updated successfully, but these errors were encountered: