Endianness (big vs little): Question bank — Hardware deep dive

Before you start, recall the two facts everything below rests on:

A byte is the smallest thing memory can address; a wide number is split across consecutive addresses.
Endianness only chooses the order of whole bytes — see Memory Addressing and Data Representation.

True or false — justify

Endianness changes the actual numeric value stored.

False. It only changes byte placement; the reconstructed value

V = \sum_{k} b_{k} 25 6^{k}

is identical on both machines.

Little-endian reverses the bits inside every byte.

False. Bits within a byte never move — 0x12 stays 00010010; only the ordering of whole bytes across addresses differs.

A one-byte value (like a char) is stored differently on big- vs little-endian machines.

False. A single byte occupies one address with nothing to reorder, so endianness is irrelevant to it.

The string "Hi" stored as {'H','i'} comes out byte-reversed on a little-endian CPU.

False. Array elements keep their given order on both machines; only a single multi-byte scalar is split by endianness (see the char[] mistake in the parent).

Big-endian is the objectively correct convention because it matches how we write numbers.

False. Neither is "correct"; big just looks natural in a dump. Most CPUs (x86, common ARM) are little-endian — it is purely a convention that both sides must agree on.

In big-endian, reading a single byte at the lowest address gives the low-order part of the number.

False. Big-endian puts the most significant byte at the lowest address, so that byte is the high-order part, not the low.

"Network byte order" means each machine sends bytes in its own native order.

False. Network byte order is fixed as big-endian; a little-endian host must convert (e.g. htonl) before sending — see Network Protocols.

Two machines with the same endianness never need conversion to exchange integers.

True. If both agree on byte order, the bytes on the wire mean the same value on both ends with no swap needed.

Endianness is decided freshly by each program at runtime.

False. It is fixed by the CPU's Instruction Set Architecture (ISA); a program cannot change the hardware's byte order, only work around it.

Extracting a byte with >> and & 0xFF gives different results depending on endianness.

False. Shifts and masks (see Bitwise Operations) operate on the value, not on memory layout, so they are endianness-independent; only reading raw bytes through a pointer exposes endianness.

Spot the error

"To store 0x12345678 little-endian at address A, write 12 at A, 34 at A+1, 56 at A+2, 78 at A+3."

Wrong — that is big-endian. Little-endian puts the LSB first: A:78, A+1:56, A+2:34, A+3:12.

"Little-endian at addresses 100:AA 101:BB 102:CC 103:DD holds the value 0xAABBCCDD."

Wrong. In little-endian the byte at the lowest address is the LSB, so the value is

0xDDCCBBAA

, not 0xAABBCCDD.

"Value 5 stored in 4 bytes little-endian is 100:00 101:00 102:00 103:05."

Wrong — that is big-endian. Little-endian places the nonzero low byte first: 100:05, 101:00, 102:00, 103:00.

"To detect endianness, store int x = 1 and check if all four bytes equal 1."

Wrong. Only one byte is nonzero (value 1 has bytes 01 00 00 00); you check the byte at the lowest address — 1 means little-endian, 0 means big-endian (see Pointers and Type Punning).

"Casting a 4-byte int* to a char* and reading index 0 always gives the most significant byte."

Wrong. Index 0 is the lowest address, which holds the least significant byte on little-endian and the most significant on big-endian — the result depends on the machine.

"Big-endian offset formula is mem[i] = b_i for an N-byte value."

Wrong. Big-endian reverses the index:

mem [i] = b_{N - 1 - i}

. It is little-endian that uses

mem [i] = b_{i}

Why questions

Why do two endianness conventions exist at all instead of one universal rule?

Because addresses are linear but numbers span several bytes, so a CPU must pick a lay-out order; there is no cosmic-correct choice, so different designers picked differently.

Why is little-endian convenient for reading a value at a smaller width?

The low-order byte sits at the lowest address, so reading 1 byte already gives the correct low part and widening 8→32 bits needs no address change.

Why is big-endian used as "network byte order"?

A single fixed convention was needed so machines of any native order interoperate; big-endian was chosen for TCP/IP so all hosts convert to the same order before transmitting.

Why does endianness never affect a byte array or string?

Endianness only governs how one multi-byte scalar is split; array elements are independent addressable units already placed in program order.

Why can the union/pointer trick reveal endianness with the value 1?

The value 1 has exactly one nonzero byte (0x01); its location (lowest vs highest address) directly exposes which byte the machine put first.

Why does little-endian simplify carry-propagation hardware?

Arithmetic carries flow from the least significant end upward; with the LSB at the lowest address the adder can start at the base address and march forward in step with the carry.

Edge cases

Does endianness matter for a value that fits in a single byte, like uint8_t?

No. With only one byte there is nothing to reorder, so both conventions store it identically.

What happens if you store 0x00000000 — can you tell the endianness from its bytes?

No. All four bytes are 00, so big- and little-endian layouts are byte-for-byte identical; a symmetric value hides the convention.

Is a palindromic value like 0x12211221 byte-reversal-invariant?

Its byte sequence 12 21 21 12 is a palindrome, so big- and little-endian layouts happen to look the same in memory even though the convention still logically differs.

If a struct has a 1-byte field followed by a 4-byte int, is the 1-byte field affected by endianness?

No — only the 4-byte int is split by endianness; the single-byte field keeps its lone position regardless (padding/alignment is a separate concern).

Can mixing endianness within one program ever happen?

Yes — "middle-endian" or mixed layouts historically existed, and code handling both native data and big-endian network data effectively juggles two orders, converting at the boundary.

If two hosts have opposite endianness, what breaks when they share an integer without conversion?

The receiver reconstructs the bytes in the wrong order, yielding a byte-swapped (usually nonsensical) value; only a single-byte field or a symmetric value survives unscathed.

Recall One-line summary of the whole trap set

Same number, different byte order; bits inside a byte never move; single bytes and byte arrays are immune; and the only "correct" endianness is the one both sides agreed on.

Connections

Instruction Set Architecture (ISA) — endianness is fixed by the CPU's ISA.
Memory Addressing — traps rely on the low-address/high-address distinction.
Data Representation — value vs byte-layout separation is the core insight.
Network Protocols — big-endian network byte order and conversion boundaries.
Pointers and Type Punning — the detection trick and char* casting cases.
Bitwise Operations — shifts/masks are endianness-independent, unlike raw byte reads.