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

char ≥ 8, short ≥ 16, int ≥ 16, long ≥ 32, long long ≥ 64. Why these numbers matter: the standard promises minimums only. int might be 16, 32, or 64 bits in real life — but never fewer than 16. So the only size you may safely assume is "at least this".

False. sizeof is defined to count in units of char. A char occupies "1 char" by that very definition, so sizeof(char) == 1 always, on every conforming C compiler — even on an exotic machine where a char is 9 or 16 bits wide. The number of bits can vary; the number of chars cannot.

#include <stdint.h>. The 32 promises exactly 32 bits, signed, two's complement, on every platform — no minimums, no "it depends". Reading the name gives you the size. See Two's complement & integer overflow for what "two's complement" means.

$N=16$ bits, unsigned. Distinct values $=2^{16}=65536$. They run $0,1,\dots ,2^{16}-1$, so the maximum is $2^{16}-1=65535$. Why $2^{16}$? 16 switches, each doubling the count: $2\times 2\times \cdots$ (16 times) $=2^{16}$. We start counting at 0, which is why the biggest number is one less than the count.

$N=32$, signed two's-complement. Range $[-2^{31},2^{31}-1]$. $-2^{31}=-2147483648,2^{31}-1=2147483647.$ Why the asymmetry (one more negative than positive)? Zero eats a slot on the non-negative side. The $2^{32}$ patterns split into $2^{31}$ negatives and $2^{31}$ non-negatives; but the non-negatives include $0$, leaving only $2^{31}-1$ positive values. This is the INT32_MAX macro's value.

$N=8$, unsigned: max $=2^8-1=255$. So uint8_t holds exactly $0\dots 255$ — precisely the range of one raw byte. That is why image pixels, network bytes, and buffers use uint8_t. (Plain char might be signed, giving $-128\dots 127$, which is wrong for a raw byte — see the L2 trap.)

Look at the ABI figure below — it shows exactly where the two platforms disagree.

The one line that differs is long. LP64 = "Long and Pointer are 64-bit". LLP64 = "Long Long and Pointer are 64-bit" — long stays 32-bit (4 bytes) so old Windows code that assumed long == int keeps working. This single row is the whole reason int64_t exists.

It does not give 10. An array parameter decays to a pointer — inside len, a is an int*, not an array. So sizeof(a) is the pointer size = 8 (LP64), and sizeof(a[0]) = sizeof(int) = 4. Result: $8/4=2$. Wrong. Why the trick works in main but not here: in main, sizeof data sees the whole real array (10 × 4 = 40 bytes), so 40/4 = 10. The moment the array is passed to a function, only a pointer travels. See Pointers and array decay. Fix: pass the length as a separate parameter.

sizeof yields a size_t, which is unsigned and often 64-bit. %d tells printf to read a signed 32-bit int off the argument stack. That is a type mismatch between what you passed (size_t) and what printf reads (int) → undefined behaviour. It happens to look fine for the tiny value 4, but on other values/platforms it can print garbage or misalign later arguments. Fix: use %zu, the specifier built for size_t. See printf format specifiers and size_t and ptrdiff_t.

#include <stdint.h>
typedef struct {
    uint16_t port;      // exactly 2 bytes, unsigned (ports are 0..65535)
    uint32_t ip;        // exactly 4 bytes (IPv4 is 32 bits)
    int64_t  timestamp; // exactly 8 bytes, signed (time can be pre-1970)
    uint8_t  flags;     // exactly 1 byte of bit-flags
} Header;

Why fixed-width everywhere? If you used short/int/long, long alone is 8 bytes on Linux but 4 on Windows — the two machines would lay the bytes out differently and could not parse each other's packets. uintN_t nails the layout on every platform. Caveat: the field sizes are now fixed, but the compiler may still insert padding between fields, and byte order still differs — see Struct padding & alignment and Endianness & serializing data before you actually put this on a wire.

3 billion $>2^{31}-1=2147483647$, so a 32-bit signed type overflows. You need at least 32 unsigned bits or 33+ signed bits, and you want speed, not an exact size. Pick uint_fast32_t (≥32 bits, unsigned, the fastest such type) — or int_fast64_t if you want signed headroom. Why not int32_t? That is signed 32-bit, max $2147483647<$ 3 billion → overflow, undefined behaviour (see Two's complement & integer overflow). Why not int64_t? It works, but it forces 64 bits even on a chip where a 32-bit register is faster. ..._fast.. says "give me at least this range, but choose the speed-optimal width for this CPU." Exact width matters for layout (packets); it does not matter for a private in-memory counter.

printf("%zu\n", sizeof v / sizeof v[0]);

Prints 7 on every platform. Reason: sizeof v = total bytes of the whole array = $7\times \text{sizeof(double)}$, and sizeof v[0] = sizeof(double). The sizeof(double) cancels: $\frac{7\times s}{s}=7$, independent of what s actually is. This is why the idiom is portable — it never mentions a concrete size. (Works only because v is a real array here, not a decayed pointer parameter — contrast L3.2.)

Proof. $N$ bits give $2^N$ distinct patterns (each bit is an independent switch, doubling the count). Two's complement assigns these patterns so that:

• the $2^{N-1}$ patterns whose top bit is $0$ represent $0,1,\dots ,2^{N-1}-1$ (the non-negatives),
• the $2^{N-1}$ patterns whose top bit is $1$ represent $-2^{N-1},\dots ,-1$ (the negatives).

Adding the two groups: $2^{N-1}+2^{N-1}=2^N$ patterns, all used, none repeated. The smallest is $-2^{N-1}$; the largest is $2^{N-1}-1$. $■$

For int16_t, $N=16$: range $[-2^{15},2^{15}-1]=[-32768,32767]$. Edge note: there is exactly one more negative than positive value ($-32768$ has no positive twin). That lone extreme, $-2^{N-1}$, is the classic overflow landmine — negating it does not fit. See Two's complement & integer overflow.

sizeof(int) returns the size in units of char — i.e. how many chars an int is. The number of bits is sizeof(int) * CHAR_BIT, where CHAR_BIT (from <limits.h>) is the bits per char. On every mainstream machine CHAR_BIT == 8, so sizeof(int)*8 is correct there. It can fail on historical/DSP hardware where a char is 9, 16, or 32 bits — then CHAR_BIT != 8 and you must multiply by CHAR_BIT, not 8. Mastery point: sizeof counts chars, and chars are not universally 8 bits — that assumption is the hidden one.

Not guaranteed. Fixed-width types pin each field's size, but the compiler may insert padding so that each field lands on its natural alignment boundary. A uint32_t typically wants a 4-byte-aligned address, so after the 2-byte uint16_t the compiler inserts 2 padding bytes, then the 4-byte field. Layout: [u16 = 2][pad = 2][u32 = 4] → sizeof = 8, not 6. The struct is also usually padded up to a multiple of its largest alignment. Takeaway: stdint.h fixes field widths, not the whole-struct size or spacing — for that you need Struct padding & alignment (and packing pragmas) plus Endianness & serializing data when the bytes leave the machine.

intN_t? $-2^{N-1}$ and $2^{N-1}-1$. Plug $N$ = 8, 16, 32, 64.

long: 8 bytes on LP64 (Linux/macOS), 4 bytes on LLP64 (Windows). Everything else in the common set matches.

sizeof(v)/sizeof(v[0]) fail inside a function that took v as a parameter? The array parameter decayed to a pointer; sizeof(v) is the pointer size, not the array size.