Type sizes — sizeof, platform dependency, stdint.h (int32_t etc.): Worked examples

This page is the "hands dirty" companion to Type sizes — sizeof, platform dependency, stdint.h (int32_t etc.). We will walk through every kind of situation the topic can throw at you: reading sizeof, the platform split, the overflow edge, the degenerate zero-width cases, a real network word-problem, and a nasty exam twist. Each example first asks you to guess, then shows every step with a reason, then verifies the number.

Before we start, one reminder in plain words: a byte here means "one char", and sizeof is a ruler that measures how many of those char-slots a thing takes. Nothing below assumes you already trust any size — we compute each from the rule that gave it.

The scenario matrix

Every worked example below is tagged with the cell of this matrix it covers. Together they touch every cell.

Cell	What makes it different	Covered by
A. Basic measure	Read a size straight from `sizeof` on one known ABI	Ex 1
B. Platform split	Same type, different answer on LP64 vs LLP64 vs 16-bit	Ex 2
C. Signed max/min	Largest & smallest value that fits (both signs)	Ex 3
D. Unsigned wrap (limiting value)	Value at the very edge, and one step past it	Ex 4
E. Zero / degenerate input	Empty array, `sizeof` of a zero-length-ish thing, `sizeof(char)`	Ex 5
F. Array length trick + decay trap	`sizeof arr / sizeof arr[0]` working vs silently broken	Ex 6
G. Real-world word problem	Design a packet struct with fixed widths	Ex 7
H. Exam twist	A mixed signed/unsigned comparison that surprises everyone	Ex 8

Figure — Type sizes — sizeof, platform dependency, stdint.h (int32_t etc.)

The picture above lays the same eight cells on a number line of "how many bits" so you can see where each example lives: the small toy-computer end (16-bit), the mainstream middle (32-bit), and the wide end (64-bit).

Ex 1 — Cell A: Basic measure

Worked example Statement

On a 64-bit Linux machine (the LP64 ABI), what does this print?

printf("%zu %zu %zu\n", sizeof(char), sizeof(int), sizeof(double));

Forecast: write down your three numbers before reading on.

Steps.

sizeof(char) is 1. Why this step? Because the standard defines sizeof to count in units of char. A char is one char wide — always, on every machine. This is the one size you never have to look up.
sizeof(int) on LP64 is 4. Why this step? The standard only promises int ≥ 16 bits. LP64 (Linux/macOS 64-bit) chooses 32 bits = $32/8 = 4$ bytes. We read this from the ABI table, not from a guess.
sizeof(double) is 8. Why this step? An IEEE-754 double-precision float is 64 bits by design; $64/8 = 8$ bytes. This is stable across the mainstream ABIs.

Answer: 1 4 8.

Ex 2 — Cell B: The platform split

Worked example Statement

The same line

printf("%zu\n", sizeof(long));

is compiled on three targets: 64-bit Linux (LP64), 64-bit Windows (LLP64), 16-bit DOS. What three numbers come out?

Forecast: most people say "8, 8, ...". Commit to all three.

Steps.

LP64 → long is 8. Why this step? "LP64" literally means Long and Pointer are 64-bit. $64/8 = 8$ .
LLP64 → long is 4. Why this step? "LLP64" means only Long-Long and Pointer are 64-bit; plain long stays 32-bit. $32/8 = 4$ . This is the killer detail from the parent note.
16-bit DOS → long is 4. Why this step? Old 16-bit int was 2 bytes, but long still had to satisfy the "≥ 32 bits" floor, so it was 4.

Answer: 8, 4, 4.

The figure shows the three memory boxes side by side: notice the LP64 box is twice as wide as the LLP64 box for the identical type name long. That visual mismatch is exactly the bug that bites cross-platform code.

Ex 3 — Cell C: Signed max and min

Steps.

Count the patterns: 16 switches → $2^{16} = 65536$ distinct bit patterns. Why this step? Every bit is an independent on/off switch; each doubles the count, giving $2^{N}$ . This is the from-scratch derivation the parent used.
Split for signed two's complement: half go to negatives, half to non-negatives. Range $= [- 2^{N - 1}, 2^{N - 1} - 1]$ with $N = 16$ . Why this step? The top bit acts as a sign region; the $2^{16}$ patterns split into $2^{15}$ negative and $2^{15}$ non-negative (which includes zero). See Two's complement & integer overflow for why the negatives get the exact half they do.
Plug in: max $= 2^{15} - 1 = 32767$ , min $= - 2^{15} = - 32768$ . Why this step? The non-negative side spends one pattern on zero, so its top is $2^{15} - 1$ ; the negative side has no zero to spend, so it reaches one further, to $- 2^{15}$ . They are not symmetric — there is one more negative than positive.

Answer: max 32767, min -32768.

Ex 4 — Cell D: Unsigned wrap at the limiting value

Steps.

Range of uint8_t: $0 \dots 2^{8} - 1 = 0 \dots 255$ . Why this step? Unsigned counts from 0, so the top is $2^{N} - 1$ . $x = 255$ is sitting exactly on the ceiling.
Compute $255 + 1 = 256$ — but 256 needs a 9th bit, which does not exist in 8 bits. Why this step? We must check whether the mathematical result still fits; it does not, so the language rule for unsigned takes over.
Unsigned overflow wraps modulo $2^{8} = 256$ : result $= 256 mod 256 = 0$ . Why this step? The C standard defines unsigned arithmetic as arithmetic modulo $2^{N}$ — the extra high bit is simply discarded, like an odometer rolling from 999 to 000. (Careful: because of Integer promotion & usual arithmetic conversions, x + 1 is first computed as int, giving 256, then the assignment back to uint8_t performs the modulo. The final stored value is still 0.)

Answer: 0.

Ex 5 — Cell E: Zero / degenerate inputs

Steps.

(a) sizeof(char) is 1, by definition, forever. Why this step? sizeof measures in units of char, so char measures 1 of itself. Even on a hypothetical machine where a char is 9 or 16 bits, sizeof(char) is still 1 — it counts chars, not bits.
(b) A zero-length array has 0 elements × element-size = 0 bytes, so sizeof a is 0 on compilers that allow it. Why this step? Total size = count × per-element size = $0 \times 4 = 0$ . This is the degenerate "empty ruler" case — it multiplies down to nothing.
(c) An empty struct is not legal in standard C (it is in C++, where sizeof would be 1). In C you must give a struct at least one member. Why this step? The scenario matrix demands we cover the illegal degenerate input too, not just the small one — the correct answer here is "this doesn't compile", not a number.

Answers: (a) 1; (b) 0; (c) compile error in standard C.

Ex 6 — Cell F: Array-length trick and the decay trap

Worked example Statement

On LP64:

void f(int arr[]) {
    printf("in f:   %zu\n", sizeof(arr) / sizeof(arr[0]));
}
int main(void) {
    int a[10];
    printf("in main: %zu\n", sizeof(a) / sizeof(a[0]));
    f(a);
}

What are the two printed numbers?

Forecast: both 10? Commit before reading.

Steps.

In main: a is a real array of 10 int. sizeof(a) = 10 × 4 = 40, sizeof(a[0]) = 4. Why this step? a genuinely occupies 40 contiguous bytes, and the ruler sees all of them.
Divide: $40/4 = 10$ . Correct element count. Why this step? Total bytes ÷ bytes-per-element = number of elements — a size-independent way to get length.
In f: the parameter int arr[] is a lie — C rewrites it to int *arr. So sizeof(arr) is the size of a pointer = 8 on LP64, and sizeof(arr[0]) is still 4. Why this step? Arrays passed to functions decay to pointers — see Pointers and array decay. The array's length is not carried along; only its first address is.
Divide: $8/4 = 2$ . Wrong — it is not 10. Why this step? The trick silently returns "pointer-size ÷ int-size", a meaningless 2, because the array's true length is gone. Fix: pass the length as a separate argument.

Answers: in main: 10, in f: 2 (on LP64).

Ex 7 — Cell G: Real-world word problem (packet struct)

Steps.

Port range 0–65535 = $0 \dots 2^{16} - 1$ → needs exactly 16 unsigned bits → uint16_t (2 bytes). Why this step? $65535 = 2^{16} - 1$ , so 16 unsigned bits fit it perfectly; a smaller uint8_t (max 255) can't hold a port.
IPv4 address = 32-bit number → uint32_t (4 bytes). Why this step? An IPv4 address is defined as exactly 32 bits (four octets). Fixed width guarantees both machines lay the same 4 bytes.
Timestamp, possibly large and negative → int64_t (8 bytes). Why this step? Negative needs signed; "large" (e.g. Unix nanoseconds) overflows 32 bits, so we choose 64.
Add the data sizes: $2 + 4 + 8 = 14$ bytes. Why this step? We sum the guaranteed widths. Every platform agrees on this data total because every field is fixed-width — the whole reason we avoided int/long.

Answer: struct with uint16_t, uint32_t, int64_t; 14 bytes of data.

Ex 8 — Cell H: The exam twist (signed vs unsigned compare)

Worked example Statement

int   a = -1;
unsigned int b = 1;
if (a < b) puts("less");
else       puts("not less");

On any mainstream 32-bit-int platform, which line prints?

Forecast: "−1 is obviously less than 1, so less." Are you sure?

Steps.

Spot the mixed types: a is signed int, b is unsigned int. C must convert them to a common type before comparing. Why this step? Comparison needs both operands the same type; C applies the usual arithmetic conversions — see Integer promotion & usual arithmetic conversions.
The rule: when signed and unsigned int meet (same rank), the signed operand is converted to unsigned. Why this step? Unsigned "wins" at equal rank. So a = -1 is reinterpreted as an unsigned value.
Convert $- 1$ to unsigned int (32 bits) modulo $2^{32}$ : $- 1 mod 2^{32} = 2^{32} - 1 = 4294967295$ . Why this step? Two's-complement all-ones is $2^{32} - 1$ ; converting a negative to unsigned adds $2^{32}$ until it's in range. So a becomes a huge number.
Compare $4294967295 < 1$ ? False. So the else runs. Why this step? After conversion the comparison is between two unsigned values, and $4294967295$ is not less than $1$ .

Answer: prints not less — the surprising branch.

Recall — cover the whole matrix

Recall Which cell does each idea live in?

Basic read → A. Same type, different size across ABIs → B. Signed max/min asymmetry → C. Unsigned edge wrap → D. Empty/illegal degenerate → E. Length trick vs decay → F. Packet design → G. Signed/unsigned compare surprise → H.

Recall Why does Ex 8 not print "less"?

The signed -1 is converted to unsigned (becomes $2^{32} - 1$ ) before the comparison, so it is larger than 1, not smaller.

Recall Why is

int16_t min -32768 but max only 32767? Two's complement has one more negative than positive: $[- 2^{15}, 2^{15} - 1]$ , because the non-negative side must spend one pattern on zero.

Connections

Type sizes — sizeof, platform dependency, stdint.h (int32_t etc.) (parent)
Two's complement & integer overflow
Integer promotion & usual arithmetic conversions
Pointers and array decay
Struct padding & alignment
Endianness & serializing data
printf format specifiers
size_t and ptrdiff_t