Scratchpad

[chfast]

The idea behind this is the following:

1. Scratchpad is a small buffer attached to evmc_result. That's there is up the the creator of the evmc_result object.
2. The VM can copy small EVM outputs there (no dynamic allocation). Usually solidity functions return nothing or 32 bytes.
3. This is also the way to deliver "create address" from Client to VM. Union is used because the "create address" and output is never needed at the same time.

[gumb0]

I think it certainly looks simpler without additional free functions

[axic]

I think for a 4 byte saving this complicates matters too much for bindings, such as go or rust.

[chfast]

Risks:

1. In theory, union memory layout is not binary compatible across different compilers / compilers versions.
2. Not everything FFI/bindings support unions. E.g. Go will represent this union as bytes.
3. Using the same memory space for different purposes.

A more conservative variant is to place the scratchpad after create_address.

[chfast]

Update version: create_address separated from the scratchpad.

Still union is used - this is the easiest way to make sure the scratchpad is aligned memory (fix needed for 32-bit arch). However, using unions still might be not ideal for bindings.

Alternatively, we can define scratchpad as uint8_t scratchpad[32 + 4] and then add helpers like:

uint64_t* get_scratchpad_as_words(result*)
{
    (uint64_t*)&result->scratchpad[4];
}

[axic]

Added the size tests to Rust too.

[axic]

@chfast how about this PR? The current version seems to be good, at least from the C and Rust perspectives.

[chfast]

Not now. I have some other ideas in this subject.