Skip to main content
Commonmark migration
Source Link

Nice catch. Its not bug, your getting different results because of public and external functions will handle memory differently.

In solidity public function immediately copies array arguments to memory. While copying to memory EVM will do 32 bytes padding.

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.

`external` vs `public` best practices

Nice catch. Its not bug, your getting different results because of public and external functions will handle memory differently.

In solidity public function immediately copies array arguments to memory. While copying to memory EVM will do 32 bytes padding.

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.

`external` vs `public` best practices

Nice catch. Its not bug, your getting different results because of public and external functions will handle memory differently.

In solidity public function immediately copies array arguments to memory. While copying to memory EVM will do 32 bytes padding.

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.

`external` vs `public` best practices

deleted 14 characters in body
Source Link

Nice catch. Its not bug, your getting different results because of public and external functions will handle memory differently.

In solidity public function immediately copies array arguments to memory. When your coping values inWhile copying to memory itEVM will padding withdo 32 bytes padding.

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.

`external` vs `public` best practices

Nice catch. Its not bug, your getting different results because of public and external functions will handle memory differently.

In solidity public function immediately copies array arguments to memory. When your coping values in to memory it will padding 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.

`external` vs `public` best practices

Nice catch. Its not bug, your getting different results because of public and external functions will handle memory differently.

In solidity public function immediately copies array arguments to memory. While copying to memory EVM will do 32 bytes padding.

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.

`external` vs `public` best practices

deleted 10 characters in body
Source Link

Nice catch. Its not bug, your getting different results because of public functions and external functions will handle memory differently.

In solidity public function immediately copies array arguments to memory. When your coping values in to memory it will padding 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.

`external` vs `public` best practices

Nice catch. Its not bug, your getting different results because of public functions and external functions will handle memory differently.

In solidity public function immediately copies array arguments to memory. When your coping values in to memory it will padding 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.

`external` vs `public` best practices

Nice catch. Its not bug, your getting different results because of public and external functions will handle memory differently.

In solidity public function immediately copies array arguments to memory. When your coping values in to memory it will padding 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.

`external` vs `public` best practices

deleted 17 characters in body
Source Link
Loading
added 1 character in body
Source Link
Loading
added 33 characters in body
Source Link
Loading
added 97 characters in body
Source Link
Loading
deleted 11 characters in body
Source Link
Loading
Source Link
Loading