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
Bytes.md has a section which says "Ethereum uses the big endian format when working with strings/bytes, and little endian when working with other types (such as numbers and addresses)." and proceeds to give examples of the same, but it doesn't match conventional use of the term endianness.
A 32-byte number 0x61626364 in little endian format would be represented as 0x64636261000..., the example given is actually the big endian representation.
(Minor nitpick) Endianness is usually specified for multibyte values while UTF-8 strings are usually considered an array of single byte values. Don't think it is the right term to use for strings.
I'm not sure if there's an ideal term for what its trying to demonstrate (something around padding maybe?), perhaps someone more knowledgeable can chime in here.
The text was updated successfully, but these errors were encountered:
Ah yes, the concept of alignment would fit pretty well.
The ABI spec here seems to use versions of "padded on left/right" in most places and "left-align" in one of the examples so using either would be fine.
Bytes.md has a section which says "Ethereum uses the big endian format when working with strings/bytes, and little endian when working with other types (such as numbers and addresses)." and proceeds to give examples of the same, but it doesn't match conventional use of the term endianness.
0x61626364
in little endian format would be represented as0x64636261000...
, the example given is actually the big endian representation.I'm not sure if there's an ideal term for what its trying to demonstrate (something around padding maybe?), perhaps someone more knowledgeable can chime in here.
The text was updated successfully, but these errors were encountered: