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
Similarly to #638, we want to serialize all the arguments into a single Vec<u8>. Further, we need to make sure that the bytes aren't dropped before they're read by the host.
I'm going to propose that all host functions (on the Rust side) have a safe wrapper and that their actual definition is written with a macro instead of being called directly.
Here the macro would actually define the external function. Alternatively, if there is no module, there should be another pattern to patch the following:
richardpringle
changed the title
[x/programs] All host functions (that get linked) should can the same two argument calling convention
[x/programs] All host functions (that get linked) should follow the same two argument calling convention
Apr 25, 2024
TODO: after merging #872, we should serialize the parameters being (ptr_offset, data_len)* with Borsh and just pass one of these CPointer which will simplify the API a lot.
TODO: after merging #872, we should serialize the parameters being (ptr_offset, data_len)* with Borsh and just pass one of these CPointer which will simplify the API a lot.
Going to close this as #900 essentially achieves everything we want. I think we want to make one more minor change in that we want to generically call functions with context + n args (including the trivial case)... but I don't think we need an issue tracking that.
Similarly to #638, we want to serialize all the arguments into a single
Vec<u8>
. Further, we need to make sure that the bytes aren't dropped before they're read by the host.I'm going to propose that all host functions (on the Rust side) have a safe wrapper and that their actual definition is written with a macro instead of being called directly.
Right now, the code looks something like this:
But this functionality should look something like this:
Here the macro would actually define the external function. Alternatively, if there is no module, there should be another pattern to patch the following:
Inside the macro, the actual name of the function inside the
extern
block doesn't matter; it's only the link name that does something.Could also fix #849 while fixing this.
The text was updated successfully, but these errors were encountered: