-
Notifications
You must be signed in to change notification settings - Fork 5.7k
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
Feature: Add bytes building method #1707
Comments
This was planned under the name |
Yes, this would be amazing. Just think: proxy contracts, multisig wallets, anything with a forward method would need and use this. |
Could you formalize your specification a bit more? I actually see three different ways of doing this. |
So I would say just like call: Definition: Usage:
Perhaps that first argument needs to be different or special for the proper bytes4 packing, like with call. But everything else can just be properly packed (with padding in the front and not in the back).
|
|
So everything is ABI-encoded, but if the first argument is a bytes4, it is not padded and the offset of the ABI-encoding starts from the second argument? |
@chriseth yes, similar to call, although would there be a better way to do this that is more general but allows me to form the proper 4 byte method sig at the beginning? |
Alternate or additional idea:
How about having a function that can be called on |
Also, I see two distinct functions here.
|
Back at the proposal of macros, one of the motivations was to have all of these abstracted and today with the intermediate language, it seems very feasible. Also it always comes up as a feature request when implementing proxies :) It would be nice to have the following: a) inline assembly methods:
b) higher level methods:
We could implement I am also open to only expose the low level methods under the |
@axic any ETA on these features. I'm dying for these. Super priority for multi-sig wallet/governance building on Eth. Also, a general decode would be amazing. Right now I need to decode by hand, which is very dangerous. |
We could already do that without inline assembly, actually I don't see the big benefit anyway. We might use the new "callLowLevelFunction" feature and easily turn these into assembly functions at a later point in time. Also we might do without tight encoding for now (tight encoding is very different for dynamic data). |
@chriseth could you expand? Also, what is the easiest way to pull and compare a method signature form a bytes data store? I want to get the method sig from the first 4 bytes. What do you recommend? In fact, what is the best way to pull the first 4 bytes in general and store in a bytes4 store (if possible). |
@SilentCicero expand on what? The comment above was basically an idea about how to implement these changes internally. About extracting the method signature:
If you just want to have the signature of the current call, you can also use |
@chriseth thanks for expanding, makes sense. Assembly is nice and simple =D |
Regarding this issue, could I please get your input on this? What should be the correct behavior for a function like approveAndCall? Should it expect its 'extraData' parameter to be ABI encoded already or encode it before making the call? |
Here's an old Pivotaltracker version of the issue: https://www.pivotaltracker.com/n/projects/1189488
|
We are still missing the changelog entry and the documentation. |
Can we have a simple method that nicely and tightly packs things properly like what .call does and returns it in bytes.
A literal copy and past job of what the call method does. Just expose the subroutine for call, that aids in the building of bytes data.
That way I could build transactions by running a sequence like this:
pack
here being the bytes packing method.The only alternative right now that I can see is doing crazy things like this:
I think the building of bytes data will be critical going forward, and we should have reliable and simple ways to build bytes data for proxy forwarding.
The text was updated successfully, but these errors were encountered: