Events emitted from external functions log different data than public functions

[carver]

I posted full reproduction details on StackExchange

The short version is that calling these two functions produces different log output:

pragma solidity 0.4.19;

contract EmitStringPublicAndExternal {
    event EmitString(string logme);

    function logPublic(string logme) public {
        EmitString(logme);
    }

    function logExternal(string logme) external {
        EmitString(logme);
    }
}

When I call both functions with "glitch" (in geth --dev), I get logs with two different data:

• public: 0x00000000000000000000000000000000000000000000000000000000000000200000000000000000000000000000000000000000000000000000000000000006676c697463680000000000000000000000000000000000000000000000000000
• external: 0x00000000000000000000000000000000000000000000000000000000000000200000000000000000000000000000000000000000000000000000000000000006676c69746368

Note: "glitch" encoded with UTF-8, and then hex-encoded, is: 0x676c69746368

[axic]

Good catch. public should be the correct one :)

0000000000000000000000000000000000000000000000000000000000000020
0000000000000000000000000000000000000000000000000000000000000006
676c697463680000000000000000000000000000000000000000000000000000

[chriseth]

Does this also happen with the new encoder?

[jitenhub]

Nice catch. But its not bug its depends on memory allocation, In solidity all public functions immediately copies arguments to memory. In this process of copying values in to memory EVM will pad with 32 bytes.

EmitString(logme)

0x00000000000000000000000000000000000000000000000000000000000000200000000000000000000000000000000000000000000000000000000000000006676c69746368

As per EVM documentation EmitString(logme) logme is string type saving or representation would be 1st 32 bytes(32*2=64 chars) will represents location of string

0x0000000000000000000000000000000000000000000000000000000000000020 = 32

Now pointer will move to 33bytes to next 32 bytes is length so length is

0000000000000000000000000000000000000000000000000000000000000006 = 6, i.e next 6 bytes are data.

676c69746368 hex representation of string.

Memory representation of any bytes is padded with multiples of 32 bytes. Thats a reason you are getting 676c697463680000000000000000000000000000000000000000000000000000

Where is case of external functions can read directly from calldata. What is values your passing it will send same thing to the network. So thats reason you able to see only 676c69746368

Memory allocation is expensive, whereas reading from calldata is cheap.

That means its not a bug.

[chriseth]

@jitenhub all you say is correct, but what is your point?

[jitenhub]

@chriseth Its not bug

[chriseth]

@jitenhub I would still say we should properly ABI-encode calldata arrays with padding.

[chriseth]

The padding should be added at ArrayUtils.cpp:309.

[chriseth]

Finished work on this, but cannot push to github from this network. Hope I can push later today.

[chriseth]

Note that as soon as this is merged, it is not possible to forward bytes data anymore via call. We need #3955 for this, but that is a breaking change.

[chriseth]

Result of discussion: Add a warning for hash functions, and do the rest (including call*) with 0.5.0 proper.