The editorial argues that while the 2025 winners deserve attention, the more durable artifact is the rulebook itself. Read chronologically, each rule patches a previous exploit — making the document a de facto CHANGELOG of C as a working language and a record of which compiler corners have been pinned down over four decades.
By submitting the IOCCC 2025 winners page to Hacker News, matt_d signaled that the first results drop since 2020 — with eleven winning entries across categories like 'best abuse of the rules' and 'most enigmatic' — was significant enough to share. The 373-point score within hours validated that the broader HN community agreed this was a milestone moment for obfuscated C.
The 29th International Obfuscated C Code Contest published its 2025 winners on ioccc.org, the first results drop since 2020. Eleven winning entries across categories including *best abuse of the rules*, *most enigmatic*, and *best one-liner*. The HN announcement thread hit 373 points within hours, and the archive saw enough traffic that the judges had to tweet a CDN note.
The winners themselves will get the inspection they deserve. There are entries that implement a minimal Lisp in under a kilobyte, an X11 raytracer whose source is shaped like the rendered scene, and a one-liner that re-implements `tar` by abusing C's variable-length array semantics. Every one is worth a separate read.
But the more durable artifact this year isn't any single entry — it's the rulebook itself. The 2024-2025 ruleset is the longest in contest history: eleven numbered rules, a separate guidelines document, a reference implementation of the `iocccsize` tokenizer, and an updated FAQ that runs longer than the first contest's entire program text. The original 1984 IOCCC had two rules and fit on a typed memo.
Each new rule is essentially a patch for a previous exploit. Read chronologically, the rulebook is a CHANGELOG.md of C as a working language — a forensic record of which compiler tricks the judges no longer want to see, and by extension, which corners of the standard the compiler authors finally pinned down.
A partial timeline, drawn from the rules history the judges maintain in the archive:
- 1984: Source files counted by raw byte count. Two rules. That's the whole document. - 1988: First explicit ban on `#define`-based size cheating — contestants were packing logic into macros that exploded only after the preprocessor ran. - 1991: Trigraphs explicitly addressed after a winning entry used `??/` sequences to hide pivotal control flow from human readers. - 2004: `iocccsize` introduced — a token-aware byte counter that strips whitespace, comments, and certain reserved-word lengths before measuring. Plain `wc(1)` had become insufficient. - 2011: Rules on *secondary file processing* tightened. Several entries had been shipping Makefiles, sed scripts, or shell wrappers that did most of the program's actual work. - 2015: Size limits split into *size of the file* and *size of the abstract program*. Reflects that GCC and Clang had become aggressive enough at constant-folding that the textual size no longer matched what the optimizer actually saw. - 2020: Explicit prohibition on entries whose behavior depends on undefined behavior that produces different results across GCC, Clang, and TCC. - 2025: First disclosure requirement around AI-assisted authorship.
Each rule patch corresponds to a real compiler change: a previously exploitable corner of the standard that ISO C, GCC, or Clang has since defined, optimized away, or hardened against. Read it as a CVE feed for the language itself.
This isn't accidental. The judges — Landon Curt Noll, Simon Cooper, and the rotating panel — have always treated the contest as a kind of empirical probe into where C is loosely specified. When an entry wins by exploiting a behavior that's ambiguous in the standard, the next ruleset closes it. When the standard or the compilers later close it independently, the rule stays as a historical marker. The result is that the IOCCC archive has accidentally become one of the better empirical records of C's language drift between 1984 and now.
Community reaction on the HN thread reflects this. The top comment isn't about a specific winner; it's an observation that several pre-2000 winning entries no longer compile on modern GCC without `-std=c89 -fno-strict-aliasing -fwrapv`. A program that ran correctly under Sun C in 1989 will, on GCC 14, either fail to parse or produce different output — not because the source rotted, but because the language did.
If your team writes C or C++ — embedded, kernel, codec, database internals, anything where the toolchain matrix matters — the IOCCC rulebook is more useful than it looks. It's a curated index of which behaviors were ambiguous historically, which got pinned down, and which still vary across compilers in production today.
A practical example: the 2020 rule against *compiler-version-dependent behavior* implicitly enumerates the deltas the judges saw between GCC 9, Clang 11, and TCC 0.9.27 on real submitted code. If you're shipping a library that needs to compile cleanly under multiple toolchains, those are the same deltas your CI matrix should be exercising. Things like the evaluation order of function arguments, the value of a signed shift past the type width, what happens when you `memcpy` a non-trivial type, and whether `(int)0.5 + (int)-0.5` is zero or undefined.
The winning entries themselves are a separate kind of fossil. Many older winners no longer compile on modern toolchains — not because the code changed, but because the language did. Entries that relied on K&R-style implicit `int` declarations, signed integer overflow wraparound, sequence-point ambiguity in `a[i] = i++`, or strict-aliasing violations through `union` punning now produce errors, warnings promoted to errors under `-Werror`, or — worse — silently different output under aggressive optimization. The IOCCC archive is one of the longest-running natural experiments in C language stability, and the practical lesson is that a 25-year-old C program is no longer guaranteed to do today what it did at the time it shipped.
For a working engineer, the actionable move is small but real: when you're deciding whether to depend on a specific quirk — say, the way GCC handles `__builtin_unreachable` in a `switch` default, or Clang's treatment of `-fno-delete-null-pointer-checks` — check whether the IOCCC ruleset has touched that corner. If it has, the behavior is interesting enough that someone's already weaponized it, and your code is one optimizer pass away from breaking.
The 2025 ruleset is the first to address LLM-generated entries, and the judges chose disclosure rather than prohibition. Entries must declare AI assistance; the contest will not auto-reject them. The judges' notes hint at why: most IOCCC winners exploit interactions between the preprocessor, the parser, and the optimizer that an LLM trained on idiomatic C has no statistical reason to invent. A model that has seen ten million Stack Overflow snippets has effectively zero exposure to source code laid out as ASCII art that also happens to parse as valid C. The training data filters this material out as noise.
The practical implication is that the IOCCC will keep selecting for human compiler intuition by default, not by policy. The interesting test will come when models trained specifically on the IOCCC archive start submitting — at which point the contest becomes, intentionally or not, an eval harness for whether code-generation models can reason about C the language rather than C the corpus. Worth bookmarking the 30th edition's ruleset for that reason alone.
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.