Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

have the contents of the dispatch table respect abstraction and visibility #370

Closed
ivoysey opened this issue Sep 13, 2021 · 2 comments · Fixed by #437
Closed

have the contents of the dispatch table respect abstraction and visibility #370

ivoysey opened this issue Sep 13, 2021 · 2 comments · Fixed by #437
Assignees
Labels
Milestone

Comments

@ivoysey
Copy link
Collaborator

ivoysey commented Sep 13, 2021

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.

@ivoysey ivoysey added this to the m1 milestone Sep 13, 2021
@ivoysey ivoysey self-assigned this Sep 13, 2021
@ivoysey ivoysey added the bug label Sep 13, 2021
@ivoysey
Copy link
Collaborator Author

ivoysey commented Nov 5, 2021

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?

@ivoysey
Copy link
Collaborator Author

ivoysey commented Nov 5, 2021

this issue is somewhat entwined with #385

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
1 participant