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
I propose to remove such usage. Using unions and same fields for different purposed seems to risky. Instead, we should add 64 bytes of scratchpad in the end. This will allow current optimizations (memory stealing) but also using the space for short outputs. I expect in practice the most common output size is 32 for solidity methods returning uint256. Then outputs of size <= 64 can be copied directly to evmc_result's scratch pad.
The problem will get complicated with #413 where additional int64_t field must be added to evmc_result.
The text was updated successfully, but these errors were encountered:
The current size of
evmc_result
is 64 bytes. There also exists additional API https://github.com/ethereum/evmc/blob/master/include/evmc/helpers.h#L211 that allows to use last 24 bytes for other purposed in case.create_address
is not used. This allows to put a well implementedstd::vector
there.I propose to remove such usage. Using unions and same fields for different purposed seems to risky. Instead, we should add 64 bytes of scratchpad in the end. This will allow current optimizations (memory stealing) but also using the space for short outputs. I expect in practice the most common output size is 32 for solidity methods returning
uint256
. Then outputs of size<= 64
can be copied directly toevmc_result
's scratch pad.The problem will get complicated with #413 where additional
int64_t
field must be added toevmc_result
.The text was updated successfully, but these errors were encountered: