C's flexible integer sizes were a portability feature, not a bug, explainer argues

A viral defense of C's loose integer types

An explainer from pikuma.com, a site that teaches programming alongside retro hardware, has landed on the Hacker News front page with a defense of one of C's most-criticized traits: its integer types have no fixed size. According to the author, that looseness was not an oversight — it was the mechanism that let the language achieve portability in an era of 12-, 18-, 36- and 60-bit computers.

The starting point is a moment every C beginner hits. After learning the sizeof operator, they watch their program print 4 when asked for sizeof(int) and conclude that an integer occupies four bytes. The author, who teaches students working with vintage machines and old game consoles, then supplies a twist from personal history: on the 386 machine they first learned to code on, the same query returned 2 bytes. In C, the core types — char, short, int and long — carry no guarantee about how much memory they occupy.

The criticism the piece answers

The article is upfront that the standard complaint has merit. An int is 16 bits on one machine and 32 on another; long is 64 bits on Linux but 32 on 64-bit Windows; and the drift has produced decades of portability bugs. Given that nearly every CPU sold today is a 64-bit part comfortable with 8-, 16-, 32- and 64-bit arithmetic, why didn't C simply pin the sizes down from the start?

The author's answer is that this judges a 1970s design by 2020s conditions. C was conceived as a portable systems language that had to map efficiently onto wildly different architectures, and flexible type sizes were exactly how that mapping stayed efficient. The piece also draws a line against Java's later promise of "write once, run anywhere": C's brand of portability meant something narrower.

Word sizes before the industry settled

Today's baseline — 8-bit bytes, byte-addressable memory, 32- or 64-bit registers, two's-complement arithmetic and a flat memory model — was not guaranteed when C appeared. The explainer surveys the landscape of the 1960s and 70s:

• The DEC PDP-8, a hugely popular minicomputer, used 12-bit words.
• The DEC PDP-7, where UNIX was first written in assembly, had an 18-bit word.
• The byte-addressed DEC PDP-11, where C grew up, used 16 bits.
• The DEC PDP-10 and DECSYSTEM-20 packed characters seven or nine bits at a time inside 36-bit words; the Honeywell 6000, an early C target, also used 36-bit words with 9-bit characters.
• The UNIVAC 1100 and Unisys 2200 family performed ones'-complement arithmetic over 36-bit words and still has a C compiler today.
• The CDC 6600 had 60-bit words, 6-bit character codes and no byte addressing at all.
• On the word-addressed Cray-1, the article notes, short, int and long could all be 64 bits.

Against that backdrop, the argument goes, fixing int at 32 bits would have made C impractical on most machines that actually existed. Letting each type map to whatever the hardware handled natively was the portability strategy itself.

The modern escape hatch

For code that genuinely needs exact widths, the author points students to stdint.h, introduced with the C99 standard in 1999. Its fixed-width types — int8_t, uint8_t, int16_t, int32_t and the rest — guarantee a precise number of bits regardless of compiler or target architecture, which is why they are now the usual recommendation wherever bit-exact behavior matters.

Why it matters

The explainer's traction on Hacker News suggests the argument struck a nerve among developers. It reframes one of C's most notorious gotchas as a historically grounded decision: the language's types describe what the programmer needs, and each machine decides the representation it can execute fastest. That context does not erase the pain — the article concedes the divergent sizes have caused decades of bugs, and long still differs between Linux and 64-bit Windows. But it explains why the trade-off existed, and it stays relevant wherever code targets anything other than a mainstream 64-bit CPU, from microcontrollers to the retro consoles and vintage minicomputers the author's students work with. Judging an old language design without the hardware it was written for, the piece implies, leads to exactly the wrong lesson.