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
right now, in flat_alloc, the dispatch table contains all the functions that get flattened into the main contract as well as all the functions of the main contract. only the public ones should be there; i shouldn't expose code to the world in the process of flattening it.
a hack would be to check the function names as i process them and see if they m/(.+)___(.+)/. a somewhat better idea would be to have another data structure in YulObject that includes functions that get created by flattening methods and process them differently. adding type information per #373 may actually also address this, if that includes privacy information as well; then we know what functions ought to be world-visible, both from the main contract and from child contracts.
The text was updated successfully, but these errors were encountered:
solc outputs something like this for a setter that takes one integer argument,
case 0x60fe47b1
{
// set(uint256)
if callvalue() { revert_error_ca66f745a3ce8ff40e2ccaf1ad45db7774001b90d25810abd9040049be7bf4bb() }
let param_0 := abi_decode_tuple_t_uint256(4, calldatasize())
fun_set_13(param_0)
let memPos := allocate_unbounded()
let memEnd := abi_encode_tuple__to__fromStack(memPos )
return(memPos, sub(memEnd, memPos))
which pulls the argument from the stack. it's not clear to me how to do this when the first argument is the added implicit this argument that allows us to allocate into memory. from the outside there may not even be an instance of the object created, and in general actually won't be, so what would you even try to pass there?
right now, in flat_alloc, the dispatch table contains all the functions that get flattened into the main contract as well as all the functions of the main contract. only the public ones should be there; i shouldn't expose code to the world in the process of flattening it.
a hack would be to check the function names as i process them and see if they
m/(.+)___(.+)/
. a somewhat better idea would be to have another data structure in YulObject that includes functions that get created by flattening methods and process them differently. adding type information per #373 may actually also address this, if that includes privacy information as well; then we know what functions ought to be world-visible, both from the main contract and from child contracts.The text was updated successfully, but these errors were encountered: