Why does padding add zeros to left, but left align adds zeros to right when performing bit manipulation?

Question

I am not sure if this is a general bit manipulation related question or something specific to Ethereum. But I am reading a part of the ethereum specification here and I am confused by the bit related operations.

For instance, in the Example section a uint32 value of 69 padded to 32 bytes became 0x0000000000000000000000000000000000000000000000000000000000000045.

This I understand. Turn 69 to hex, which is 45 then pad it with 30 zeros.

But a value of "abc" after being left aligned became 0x6162630000000000000000000000000000000000000000000000000000000000

Now I am confused.

Why is it that the zeros here are added to the right? I understand where the 0x616263 comes from, which is the hex representation of "abc". But when padding the hex representation of 69 above, the zeros were added on the left, but with "abc" the zeros are being added on the right side. Why is this the case?

Answer 1

because the two data types are different:

uint32 value of 69 is an integer value, if you want to pad it to have 32-byte (the EVM native length), then you have to consider the "endianness" (Read more here):

• Big-endian: 0x0000.....0045 (32 bytes)
• Little-endian: 0x4500.....00000 (32 bytes)

This convention makes the stored value compatible with ETH yellow paper, stating clearly that it's big-endian

For "abc", it is considered an array of bytes (byte3). The solidity's convention for fixed length array of (less than 32 bytes) is "the sequence of bytes in X padded with trailing zero-bytes to a length of 32 bytes.".

Nonetheless, you can define your own convention for array (e.g. padding left for a string of less than 32 byte) if you don't use solidity and write bytecode directly to handle read/write to your array. It's because EVM bytecode does not have any knowledge or convention for array, array is totally solidity's convention.