The IOCCC 2025 winners are now posted, giving C programmers a fresh batch of code that is intentionally hard to read and still carefully engineered. The 29th International Obfuscated C Code Contest includes a Game Boy emulator, a 366-byte Subleq computer, a patch/diff quine, Quine Pong, and several entries that turn source code into a visual joke before the program even runs.
The short version
- The IOCCC 2025 winners page lists 22 winning entries for IOCCC29, including
2025/ncw1,2025/cable,2025/endoh3,2025/uellenberg, and2025/yang2. - The judges say IOCCC29 kept the high submission volume and quality seen after the contest returned from its 2020-2024 break.
- Nick Craig-Wood, Yusuke Endoh, and Don Yang each landed three winning entries, a rare enough pattern that the judges called it a “hat trick of hat-tricks.”
- The public thread focused less on clean-code lessons and more on craft: tiny virtual machines, source files shaped like hardware, old contest lore, and whether LLM-assisted entries fit the spirit of the contest.
What happened
The International Obfuscated C Code Contest published the winning entries for its 29th contest at ioccc.org/2025/. The official page points readers to each entry’s index.html, source code, author remarks, and a compressed tarball containing the full year’s winners. The judges also added small “fun challenge” prompts to this year’s entries so readers can try variants, explanations, or fixes and submit pull requests when appropriate.
The official list is broad. 2025/ncw1 is a Game Boy emulator, 2025/cable is a Subleq computer, 2025/endoh3 is a patch/diff quine, 2025/tompng generates ocean sounds, and 2025/uellenberg implements Quine Pong. The page also notes that IOCCC29 followed IOCCC28 after a 2020-2024 hiatus and still saw a similar number of submissions with high quality, according to the judges.
Why this is worth watching
IOCCC 2025 winners are useful because they show the edge cases that normal C style guides hide. The contest rewards legal, portable-enough, weird C that bends preprocessing, layout, integer behavior, build rules, and reader expectations. A clean production codebase tries to remove ambiguity; these entries make ambiguity the object of study.
That does not make the winners a model for application code. It makes them a good lab for language boundaries. A developer reading the Game Boy emulator can ask how much behavior fits into a source file. A developer reading the Subleq entry can ask how a minimal instruction set becomes a working computer. A developer reading a quine can ask where text ends and execution begins. For more programming briefs like this, the IT & AI archive keeps a running set of developer-culture notes and tool stories.
What do IOCCC 2025 winners change for developers?
The IOCCC 2025 winners do not change how teams should write maintainable C, but they are a sharp test of how well developers understand the language they use. The contest makes readers confront compilers, undefined-looking idioms, preprocessing tricks, and build assumptions without the safety rails of ordinary code review.
The AI angle is also more interesting than it looks at first. The IOCCC guidelines for Rule 7 say entrants may use tools and services including machine learning tools, natural language models, large language models, code copilot tools, and so-called AI services. The guidelines encourage authors to describe that use in remarks.md. That policy puts IOCCC in a different place from some competitions that treat AI assistance as an integrity problem. Here, authors still own the work and the judges still evaluate the result.
What Hacker News readers are arguing about
The Hacker News discussion was mostly affectionate, with a technical edge. Several readers singled out Nick Craig-Wood’s Game Boy emulator because the source code itself visually resembles a Game Boy, and one commenter noted that Craig-Wood is also the creator of rclone. Another thread centered on the 366-byte Subleq virtual machine, with readers pointing to its ability to run larger systems through a one-instruction computer model.
The skeptical comments were less about whether the winners were good and more about the surrounding process. Some readers found the IOCCC website and submission process fittingly hard to navigate, while others compared IOCCC with dormant contests such as Underhanded C. The AI thread was practical rather than alarmist: commenters noticed that the official guidelines permit LLM and copilot-style tools, then asked whether that changes the nature of the puzzle. The useful read is that IOCCC still rewards intent and taste, not only output. An LLM can help produce strange C, but the winning entries also depend on jokes, constraints, and explanations that human judges can inspect.
How to read the IOCCC 2025 winners
The IOCCC 2025 winners are easiest to enjoy when readers stop asking whether the code is “good” in the production sense. The entries are puzzles. A useful reading session has three passes: run the program, inspect the visual trick, then read the author notes and source with the build rules beside it.
| Entry type | What to inspect | What it teaches |
|---|---|---|
| Emulator or virtual machine | How much behavior fits into a tiny or shaped source file | Abstraction boundaries can be hidden in unexpected places. |
| Quine | Where input, output, patch, and source text fold into each other | Programs can treat their own representation as data. |
| Visual source | How layout carries meaning before compilation | Code can communicate with both compiler and human reader. |
| AI-assisted entry | What the author discloses and what the judges reward | Tool use does not remove the need for intent, taste, and explanation. |
The contest is also a good way to test code-understanding tools. Ask an assistant to explain one entry, then compare the answer against the official remarks and the program’s behavior. Good explanations should mention the build process, macro structure, file layout, and runtime effect. Shallow explanations will describe the theme without tracing the trick.
For developers, the lesson is not to write production C this way. The lesson is to remember how much behavior lives below normal style rules. Obfuscated code makes that visible by removing the comfort of familiar formatting.
The practical read
C developers should treat the IOCCC 2025 winners as reading material, not coding advice. Pick one entry, build it, read the author remarks, and then try to explain the trick without looking at the explanation. That exercise is more valuable than copying any particular idiom.
For tool builders, the contest is a reminder that code discovery can be playful. A repository, contest page, or developer education product does not need to flatten every program into a tutorial. Some users want puzzles, visual source code, odd constraints, and a reason to inspect the compiler’s behavior. The best entries make that inspection feel like entertainment.
For AI coding products, IOCCC is a useful stress test. Ask a model to explain 2025/cable or 2025/endoh3, then compare the explanation with the entry notes and the actual behavior. If the model gives a confident summary without tracking the build, the macros, and the file-level trick, that failure tells you something concrete about code-understanding limits.
