The editorial argues that obfuscated C winners are hand-crafted adversarial examples for any system claiming to understand C, with a small public corpus labeled by expert judges. It contrasts this with HumanEval and other vendor benchmarks, positioning IOCCC as a uniquely rigorous test that LLMs demonstrably fail by 'confidently lying' about what programs do.
Frames the five-year gap since 2020 and the delayed 2024 round as the backdrop for an edition where judges now explicitly flag entries as 'resistant to mechanical explanation.' The contest has shifted from rewarding code that defeats human intuition to rewarding code that defeats statistical intuition, without ever announcing the change.
By surfacing the 2025 winners on HN with 324 points and 76 comments, the submitter signals that the developer community sees this edition as noteworthy beyond the usual obfuscated-code curiosity. The high engagement reflects recognition that IOCCC's return lands at a moment when C comprehension itself is contested terrain.
Notes that the 2025 winners follow IOCCC's familiar taxonomy: preprocessor-as-second-language hacks, self-rendering ASCII art programs, code that compiles to three different meanings under three different standards, and one-liners hiding full interpreters. The Makefile-driven harness still works on any modern toolchain with `-std=` flags toggled, preserving continuity with four decades of prior entries.
The International Obfuscated C Code Contest published its 2025 winners at ioccc.org/2025, closing the longest gap in the contest's 41-year history. The previous edition wrapped in 2020; the 2024 round was announced, judged, and then quietly delayed into this year. This is the first IOCCC to be decided in a world where a meaningful percentage of submitted C is written, or at least nudged, by a large language model.
The winning entries follow the contest's usual taxonomy — programs that abuse the preprocessor until it becomes a second language, source files whose ASCII art renders as the program's own output, code that compiles under three different standards with three different meanings, and the perennial "Best one-liner" category where a single expression hides a working interpreter. The judges' remarks, as always, are longer than most of the programs. The full source plus build instructions for every winner is on the site; the Makefile-driven harness will compile them on any modern toolchain with a few `-std=` flags toggled.
What's different in 2025 is the judges' commentary itself. Several entries are explicitly flagged as "resistant to mechanical explanation" — a polite phrase for *we fed this to GPT and Claude and they confidently lied about what it does.* The contest has always rewarded code that defeats human intuition. This year it quietly started rewarding code that defeats statistical intuition too.
Obfuscated C is not a party trick. It is, accidentally, one of the most rigorous code-comprehension benchmarks ever assembled. Every winner since 1984 is a hand-crafted adversarial example for *any* system that claims to understand C — human or model. The corpus is small (a few hundred programs), public, version-controlled, and labeled with ground-truth behavior by judges who are, demonstrably, smarter than the average reviewer on your team.
Compare that to the benchmarks LLM vendors actually quote. HumanEval is 164 Python problems with docstrings. SWE-Bench is GitHub issues with tests already written. MBPP is freshman homework. None of them probe the things C obfuscators routinely weaponize: macro expansion order, sequence points, strict aliasing, implementation-defined behavior, trigraphs, digraphs, `#include` recursion, and the dark corners of the preprocessor where `##` token-pasting builds identifiers at compile time. An LLM trained on GitHub has seen millions of `for` loops and approximately zero programs where the `for` loop is actually a macro that expands into a switch statement inside a Duff's device.
The community reaction on Hacker News (324 points and climbing) leaned hard into this. The top comment thread isn't nostalgia — it's developers swapping screenshots of Claude 4 and GPT-5 confidently misreading the 2020 "endoh" entry, which famously rotates its own source code 90 degrees and remains a valid program. One commenter, a compiler engineer, pointed out that several winners exploit constructs the C standard committee itself takes pages to define: "If WG14 needs a footnote, the model needs a prayer."
There is a counter-argument worth steel-manning: nobody writes production code like this, so who cares if Copilot can't read it? The answer is *legacy maintenance*. The real-world cousin of IOCCC code isn't IOCCC code — it's the 1997 device driver written by someone who left the company in 2003, full of `#define`s that redefine `if`, pointer arithmetic on `void*`, and one function that's 800 lines because the original author didn't trust the optimizer. If your AI assistant can't explain an IOCCC winner, it definitely can't explain your kernel module, and the failure mode is the same: a fluent, plausible, completely wrong summary.
Three concrete moves.
First, if you ship C or C++ and you're piloting AI-assisted code review, add a handful of IOCCC winners to your internal eval set. Pick three: one preprocessor-heavy entry, one that relies on undefined behavior, one that exploits the linker. Ask your tool to explain each. The failure modes you see — hallucinated control flow, confident misidentification of which standard the code targets, silent skipping of `#pragma` directives — are the same failure modes you'll get on real legacy code, just easier to catch because the ground truth is in the judges' notes.
Second, treat the IOCCC archive as a free regression suite for your AI tooling vendor's quarterly model bumps. The archive doesn't change; the models do; the delta is a cheap, honest signal of whether "improved code understanding" in the release notes means anything for systems programming. Vendor benchmarks won't tell you this. The Python-heavy training distribution means C comprehension is the first capability to silently regress when a new checkpoint over-optimizes for LeetCode.
Third, if you're hiring for a role that involves reading other people's C — security research, embedded firmware, compiler work — the IOCCC remains the cheapest interview signal available. Show a candidate a short winner and ask them to predict the output. The ones who reach for the spec instead of guessing are the ones who'll survive your codebase.
The IOCCC organizers haven't said whether 2026 will be annual again or another five-year wait. Either way, the contest just acquired a second audience it never asked for: every team building or buying an AI code assistant that claims to handle systems languages. The winners are now eval data, the archive is a benchmark, and the judges — whether they wanted the job or not — are grading the models alongside the humans. The obfuscators won this round. The interesting question is how many rounds it takes before someone submits an entry specifically designed to be transparent to humans and opaque to transformers. Given the community, probably 2026.
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.