Bekanntgabe der Gewinner des 29. IOCCC 2025

 (ioccc.org)
3 Punkte von GN⁺ 8 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • Der International Obfuscated C Code Contest (IOCCC) ist ein Computerprogrammierwettbewerb, bei dem es um den kreativsten, künstlerischsten und zugleich am schwersten lesbaren „obfuskierten“ C-Code geht
  • Nach der Lücke von 2020 bis 2024 wurde der Wettbewerb nun zum zweiten Mal in Folge wieder veranstaltet; die Zahl der Einreichungen war ähnlich wie im Vorjahr, während Umfang und Qualität der Beiträge auf einem historischen Spitzenniveau blieben
  • Yusuke Endoh, Nick Craig-Wood und Don Yang erzielten jeweils mit drei prämierten Arbeiten einen Hattrick, außerdem gab es einen neuen Preisträger aus Taiwan
  • Unter den ausgezeichneten Arbeiten finden sich ein Subleq-Computer, ein GameBoy-Emulator, ein patch/diff-Quine und mehr; zudem wurde bei jedem Gewinnerbeitrag eine Fun challenge eingeführt
  • Die Bekanntgabe der Gewinner erfolgte in einer Live-Show auf dem YouTube-Kanal Our Favorite Universe; der nächste IOCCC30 ist für Ende 2026 geplant

Einstieg

  • Links zu den preisgekrönten IOCCC-Beiträgen 2025 finden sich unten auf der Seite in der Gewinnerliste
  • Das index.html jedes ausgezeichneten Beitrags liefert die meisten Informationen, die zum Kompilieren und Ausführen des prämierten Programms nötig sind
  • Wer den ausgezeichneten Quellcode liest und nachvollzieht, wie er funktioniert, findet weitere Details in den Erläuterungen der Autoren
  • Alle Gewinnerbeiträge des diesjährigen Wettbewerbs können als komprimiertes Tarball heruntergeladen werden

Allgemeine Anmerkungen zu diesem Wettbewerb

  • Menge und Qualität der Einreichungen bei IOCCC29 lagen nahe am historischen Höchststand
  • IOCCC28 war nach einer vierjährigen Pause der erste Wettbewerb, weshalb vermutet wurde, dass die Teilnehmer mehr Zeit hatten, ihre Beiträge zu verfeinern; das habe zu einer Rekordzahl an Einsendungen und zu einer überdurchschnittlich hohen Qualität geführt
  • IOCCC29 war zwar der zweite Wettbewerb in Folge nach der Lücke von 2020 bis 2024, doch die Zahl der Einreichungen war ähnlich wie im Vorjahr und auch die Gesamtqualität blieb hoch
  • Seit dem Abschluss von IOCCC28 wurden Fristen für neue Einreichungen, Bewertungsverfahren, die Auswahl der Gewinner, Website-Updates und der Produktionsablauf der Live-Show von Our Favorite Universe sorgfältig dokumentiert
  • Diese Dokumentation erforderte zusätzliche Zeit und Mühe, führte aber zu Verbesserungen in der gesamten Arbeitsweise des IOCCC
  • Einige Tage nach der Bekanntgabe der Gewinner von IOCCC29 auf dem YouTube-Kanal Our Favorite Universe soll die Aufzeichnung der Hauptshow in einzelne Segmente aufgeteilt werden
  • Nahe dem oberen Bereich des index.html jedes Gewinnerbeitrags soll ein neuer Abschnitt Award presentation samt Link zum jeweiligen YouTube-Segment ergänzt werden

  • Informationen zu den lustigen Herausforderungen

    • Bei den diesjährigen Gewinnerbeiträgen wurden unter dem Abschnitt „Judges’ remarks“ lustige Herausforderungen ergänzt
    • Es wird empfohlen, nach dem Verständnis der Funktion eines bestimmten Gewinnerbeitrags diese Herausforderung auszuprobieren
    • Manche Aufgaben sind leichter als andere; in manchen Fällen ist die Erstellung einer alternativen Version von prog.c oder verwandten Dateien erforderlich
    • Einige Aufgaben verlangen eine Beschreibung bestimmter Punkte
    • Wenn der Abschnitt „A fun challenge“ eines bestimmten Gewinnerbeitrags noch als still open markiert ist, kann man mit einem GitHub pull request beitragen
    • Auch wenn eine Herausforderung bereits geschlossen ist, kann weiterhin ein GitHub pull request eingereicht werden, falls man eine bessere Lösung zu haben glaubt
    • Wenn die IOCCC Judges zustimmen, dass es sich um eine bessere Lösung handelt, wird sie geprüft
    • Wer eine bessere Verbesserung für die lustige Herausforderung eines Gewinnerbeitrags hat, kann dazu einen GitHub pull request zur Prüfung durch die IOCCC Judges einreichen

  • Regeln und Richtlinien dieses Wettbewerbs

    • Die endgültigen Regeln für diesen Wettbewerb waren die 2025 rules, Version 29.15 2025-12-02
    • Die endgültigen Richtlinien für diesen Wettbewerb waren die 2025 guidelines, Version 29.08 2025-12-02
    • Die Regeln und Richtlinien von IOCCC29 wurden gegenüber früheren Wettbewerben umfassend überarbeitet
    • Mehrere Freiwillige lieferten den IOCCC Judges nützliche Bearbeitungen, sprachliche Überarbeitungen, Konsolidierungen und Verbesserungen der Gesamtstruktur

  • Auf dem Weg zum nächsten Wettbewerb

    • IOCCC30 soll gegen Ende 2026 starten
    • IOCCC30 soll über einen ähnlichen Zeitraum laufen und gegen Ende des ersten Quartals 2027 enden
    • Während die nötigen Arbeiten zur Eröffnung von IOCCC30 durchgeführt werden, ist wie zum Abschluss von IOCCC29 erneut eine Dokumentation der internen Abläufe geplant
    • Etwa zwei bis drei Wochen nach der Veröffentlichung der Gewinnerbeiträge von IOCCC29 und nachdem einige erste pull requests zum Verzeichnisbaum 2025 bearbeitet wurden, planen die IOCCC Judges eine IOCCC vacation
    • Schon nach der Veröffentlichung der Gewinner von IOCCC28 war eine IOCCC vacation geplant, doch Fehlerbehebungen und Verbesserungen im mkiocccentry repo nahmen so viel Zeit in Anspruch, dass bei Stabilisierung des Repositories bereits die Eröffnung von IOCCC29 erreicht war
    • Diesmal ist geplant, nach dem Ende der IOCCC vacation nach IOCCC29 an den mkiocccentry repo PRs zu arbeiten
    Anzeige

Anmerkungen zu einigen Gewinnerbeiträgen

  • Beim Verfassen möglicher Texte zu Einreichungen, die es bis in die letzte Runde der finalen Bewertungsrunden geschafft hatten, wurden einige Beiträge in der letzten Phase der Schlussrunde aussortiert
  • Mehrere der verbleibenden Beiträge gewannen dadurch zusätzlich an Bewunderung und höherer Bewertung
  • Die Autoren der Gewinnerbeiträge kamen teils aus Regionen mit früheren Preisträgern; bei IOCCC29 war mit jingp49 aus Taiwan aber auch eine neue Region vertreten
  • Drei Autoren gewannen jeweils mit drei Beiträgen und bildeten damit Hat-tricks eines Hat trick)
  • Einige bemerkenswerte Gewinnerbeiträge von IOCCC29 sind etwa:
  • Die obige Liste ist nur ein Teil der vielen herausragenden Gewinnerbeiträge von IOCCC29

  • Anmerkungen zu einigen nicht ausgezeichneten Einreichungen

    • Es gab zahlreiche hervorragende Einsendungen, die der finalen Auswahl sehr nahe kamen, aber keinen Preis erhielten
    • Die Mühe, die jeder Autor in seinen Beitrag gesteckt hat, wird hoch geschätzt, aber Preise können nicht allein auf Basis des Aufwands vergeben werden
    • Code, der bei IOCCC29 eingereicht, aber nicht ausgezeichnet wurde, kann nach Überarbeitung erneut bei IOCCC30 eingereicht werden
    • Mindestens einer der Gewinnerbeiträge von IOCCC29 ist eine verbesserte Version von Code, der in einem früheren Wettbewerb nicht gewonnen hatte

  • Ermutigung für Teilnehmer, die dieses Jahr nicht gewonnen haben

    • In die diesjährigen IOCCC-Einreichungen ist viel Arbeit geflossen, doch nicht alle Beiträge können ausgezeichnet werden
    • Würde jeder Beitrag einen Preis erhalten, würde das die Bedeutung jener Einreichungen schmälern, die als die besten und preiswürdig eingestuft werden
    • Selbst ein Beitrag der Finalrunde, der gut genug für einen Gewinn wäre, kann von einem ähnlichen, aber etwas besseren Beitrag übertroffen werden
    • Für Beiträge, auf die das zutrifft, wird empfohlen, eine verbesserte Version beim nächsten IOCCC einzureichen
    • Es gibt Beiträge, die erst nach mehreren Überarbeitungen Gewinnerniveau erreicht haben
    • Beim nächsten IOCCC kann auch eine völlig andere Art von Beitrag versucht werden
    • Wenn nicht geplant ist, einen nicht ausgezeichneten Beitrag verbessert erneut einzureichen, kann er veröffentlicht werden
    Anzeige

Gewinnerbeiträge kompilieren und ausführen

Gewinner des 29. IOCCC 2025

Verwandte Beiträge

1 Kommentare

 
GN⁺ 8 시간 전
Hacker-News-Kommentare

  • Der GameBoy-Emulator-Code sieht sogar wie ein GameBoy aus. So verrückt, dass man dafür langsam applaudieren möchte, und für mich persönlich der beste Beitrag dieses Jahr
    https://github.com/ioccc-src/winner/blob/master/2025/ncw1/pr...
    Der Autor Nick Craig-Wood ist die Person hinter rclone

    • Freut mich, dass es dir Spaß gemacht hat :-) Wenn du sehen willst, wie es gebaut wurde, hier ist das Original
      https://github.com/ncw/ioccc-gameboy
      Dort gibt es auch ungefähr eine nicht obfuskierte Version. Daran habe ich tatsächlich gearbeitet und anschließend mit einem Programm alle Variablennamen plattgewalzt und alles in die Form eines GameBoy komprimiert
      Die Größenbeschränkung des Beitrags war am schwierigsten. Bei IOCCC-Einreichungen sind bis zu 2503 Zeichen ohne Leerzeichen erlaubt, und die gesamte Codegröße liegt bei 4 KB, was für einen Z80-Prozessor plus GameBoy-Hardware-Emulator wirklich winzig ist
      Ich habe zuerst einen vollständigen GameBoy-Emulator in C geschrieben und bei etwa 6000 Zeichen ohne Leerzeichen angefangen. Danach habe ich ungefähr 100 Stunden darauf verwendet, ihn in das Limit von 2503 Zeichen zu pressen, und war mir eine Zeit lang nicht sicher, ob es überhaupt passen würde
      Das Ziel war, Tetris auszuführen. Tetris ist ein relativ einfaches Spiel, daher habe ich unnötige Funktionen entfernt, etwa das Half-Carry-Flag des Z80-Emulators oder das Windowing-System der GameBoy-Emulation. Außerdem habe ich den C-Code auf schreckliche Weise misshandelt und Dinge mit implicit int gemacht, die ich nie wieder vergessen werde. Da der IOCCC-Regelprüfer selbst als C-Programm implementiert ist, habe ich auch Zeit darauf verwendet, ihn zurückzuentwickeln und Schlupflöcher zu finden. Besonders nützlich war die Entdeckung, dass bestimmte Operatoren nur als ein einziges Token gezählt werden
      Als es klein genug war, musste ich auch noch ein Spiel zum Ausführen einbauen. Ich habe vier Programme erstellt: ein Testprogramm in Z80-Assembler, einen in Assembler geschriebenen Pi-Rechner, 3D-Tic-Tac-Toe in C mit gbdk-2020 und ein Schachprogramm in C. Ich habe auch festgestellt, dass auf diesem Emulator ziemlich viele Open-Source-Spiele laufen, und deshalb wenn möglich einen Downloader hinzugefügt. Überraschenderweise nutzen nicht viele Spiele BCD-Arithmetik
      Es war ein unterhaltsames Projekt
    • https://github.com/ncw/ccforth
      https://github.com/ncw/ccforth/tree/master/examples/gameboy
    • Großartig! Und ich sitze hier und mache CSS und PHP
    • Code wie ein Bild aussehen zu lassen, ist in Obfuscated-Programming-Wettbewerben ein ziemlich verbreitetes Klischee

  • Mein Favorit war der 366-Byte-C-Programm-Emulator, auf dem Linux und Doom laufen können [0]
    Diese virtuelle Maschine implementiert eine OISC, also einen Ein-Befehl-Computer [1]
    [0] https://github.com/ioccc-src/winner/blob/master/2025/cable/p...
    [1] https://github.com/ioccc-src/winner/blob/master/2025/cable/R...

    • In den letzten Wochen habe ich meine einfache Programmiersprache gebaut, die zu Linux/amd64-Assembly kompiliert wird
      Ich hätte massenhaft Standardbibliotheksroutinen wie Dateiöffnen, Shell-Befehle ausführen, strstr, strcpy schreiben können, und ehrlich gesagt habe ich im Lernprozess auch Dinge implementiert, die ich nicht gebraucht hätte. Zum Beispiel funktioniert print(getenv("HOME")). Aber mir wurde schnell klar, dass ich Beispielprogramme zum Testen und Angeben brauchte
      Also war das erste echte Programm, das ich implementiert habe, natürlich ein brainfuck-Interpreter. Dadurch ist meine Sprache jetzt indirekt Turing-vollständig
      Die erste Version brauchte 9 Minuten, um die Ausgabe des berühmten mandelbrot-Programms zu erzeugen, daher habe ich mehrere Optimierungen vorgenommen und später auch Unterstützung für switch/case eingebaut, um sie zu beschleunigen. Jetzt schafft sie dieselbe Ausgabe in 2 Minuten, also gibt es noch Verbesserungspotenzial, aber es ist schon ein ordentlicher Fortschritt
      Es war äußerst befriedigend, auf diese schummelige Art eine andere Sprache in meiner Sprache zu implementieren. Natürlich ist das alles nur zum Spaß und Lernen gedacht, und ich habe es nicht gebaut, damit irgendjemand es ernsthaft nutzt — mich eingeschlossen
      https://github.com/skx/s-lang
    • Wow! Und es implementiert eine Turing-vollständige SUBLEQ-Variante auf sehr interessante Weise

      Diese VM implementiert eine OISC, also einen One Instruction Set Computer. Dieser Befehl nimmt drei vorzeichenbehaftete 32-Bit-Operanden a, b, c und führt das Programm im Speicher m[] wie folgt aus:
      1 Der PC (Program Counter) beginnt bei 0
      2 Hole den nächsten Befehl, also die vorzeichenbehafteten 32-Bit-Operanden a, b, c
      3 Wenn bei irgendeinem Operanden das niederwertige Bit gesetzt ist, entferne dieses Bit und ersetze den Operanden durch m[operand], also den dereferenzierten Wert an dieser Adresse
      4 Setze m[b] = m[b] - m[a]
      5 Wenn m[b] kleiner oder gleich 0 ist, setze den PC auf c, andernfalls erhöhe den PC um 3 Wörter
      6 Gehe zurück zu Schritt 2

    • Die Idee gefällt mir, aber die verlinkte Eternal Software Initiative [1] ist etwas verwirrend. Es gibt mehrere Versionen der Beschreibung, wie man das dekodiert, und sie widersprechen sich teilweise
      Hier steht Set m[b] = m[b] - m[a]
      Dann wird auf die Referenzimplementierung auf GitHub [2] verlinkt, wo behauptet wird, dass man nur die Serviettennotiz [3] braucht. Dort werden alle gelesenen Werte durch 4 geteilt, und die Referenzimplementierung [4] stützt das ebenfalls. Aber es ist nicht klar, warum 4 statt 2 gewählt wurde. Es wirkt, als würde dabei ein Bit verschwendet. Ich frage mich, ob dieses Bit nötig war oder für spätere Erweiterungen reserviert wurde
      Die ursprüngliche Implementierung hat offenbar nicht durch 4 geteilt, und das scheint später hinzugekommen zu sein, aber ich verstehe nicht, warum das nötig war — außer dass es die LLVM-Codegenerierung etwas einfacher macht. Um zu prüfen, ob das beschriebene System ohne Division durch 4 unmöglich wäre, müsste man wahrscheinlich viele Beispiele durchgehen. Vermutlich hätte man nur auf gerade Adressen zugreifen können, und da der PC jedes Mal um 3 erhöht wird, wäre es sicherlich lästig gewesen, auf Codepositionen zu verweisen
      Die Referenzimplementierung hat ein magisches Verhalten bei Zugriff auf Position 64 und überschreibt dann die Positionen 64–67 mit der aktuellen Zeit. In der Serviettenbeschreibung steht das, aber auf der Hauptseite nicht
      Beide Beschreibungen erwähnen die magische Adresse -1, daher ist es seltsam, dass die implementierungsabhängige UTC-Uhr nicht ebenfalls über eine negative Adresse umgesetzt wurde, statt frei nutzbaren Speicher zu beschädigen
      Beide Beschreibungen erwähnen auch den Ablauf periodischer Timer-Interrupts, und auch das ist unerquicklich. Dabei werden Adresse 0 als Position des Interrupt-Handlers und 1 als gespeicherter PC wiederverwendet, sodass man direkt nach dem Programmstart den ursprünglichen Einstiegspunkt an Position 0 überschreiben muss
      [1] https://eternal-software.org/
      [2] https://github.com/adriancable/eternal
      [3] https://github.com/adriancable/eternal/blob/main/docs/napkin...
      [4] https://github.com/adriancable/eternal/blob/main/vm/vm.c
    • Ich habe es heruntergeladen und gebaut, und ich kann mit Sicherheit sagen, dass es das Beeindruckendste ist, was ich bisher gesehen habe
    • Das Video gibt es hier
      https://www.youtube.com/live/MoWCwZx1Swc?si=eIOlRsKWNKRVRZeB...

  • Falls es jemanden interessiert: In den Richtlinien erlaubt die IOCCC die Nutzung von LLMs ausdrücklich
    "IOCCC has a rich history of remarkable winning entries created by authors who skillfully employed various techniques (often their own tools) to develop their code."

    • Ich bin eher nicht im AI-Lager, aber diesen Fall finde ich interessant. Vor allem, weil es online nicht viele obfuskierte C-Codes gibt und LLMs bei echtem Code ohnehin Schwierigkeiten haben, die Absicht zu erschließen. Ich frage mich, ob jemand schon einmal einen Beitrag gesehen hat, der mit Hilfe eines LLM entstanden ist
      Andersherum ist es auch interessant. Wie gut kann ein LLM wohl die Funktion von obfuskiertem Code erraten?
    • Das betrifft vor allem die Juroren. Damit lässt man sich natürlich selbst die Möglichkeit offen, mit minderwertigem Code überschwemmt zu werden, aber dem Charakter des Wettbewerbs nach dürften die Juroren interessanten Code und minderwertigen Code sehr gut auseinanderhalten können
      Ich finde es gut, dass die IOCCC Code akzeptiert, der möglicherweise mit Hilfe von Maschinen entstanden ist. Dadurch wirkt der Wert rein von Hand erstellter Gewinnerbeiträge sogar noch größer
    • Ist das dann jetzt ein LLM-Gymnastik-Wettbewerb?
    • Wenn AI unter "Werkzeuge" fällt, ist Regel 7 in sich widersprüchlich
      https://www.ioccc.org/2025/rules.html
      Gemeint scheinen hier eher maßgeschneiderte Codegeneratoren zu sein. Es wird ausdrücklich von einer "reichen Geschichte" gesprochen; wenn diese Formulierung auch die Zeit vor AI einschließt, verstehe ich nicht, warum man annehmen sollte, dass damit AI gemeint ist

  • Auch die Website selbst ist obfuskiert, daher ist es überhaupt nicht leicht, den C-Quellcode zu finden

    • Man kann direkt zu https://www.ioccc.org/2025/#inventory gehen
    • Sie ist wirklich schwer zu navigieren. Man versteht kaum, worum es bei dem Wettbewerb geht, und es wirkt so, als sei sie unter der Annahme gemacht worden, dass man das bereits weiß
    • Der erste Satz führt zum Abschnitt mit der Gewinnerliste, und oben rechts bei jedem Gewinnerbeitrag gibt es einen Link C code

  • Ich wünschte, der Underhanded C Contest würde zurückkehren. Nicht, dass ich die Teilnehmer des Obfuscated C herabsetzen will, aber den fand ich persönlich viel interessanter

  • Hier gibt es eine Frieren-[1]-Anspielung!
    https://www.ioccc.org/2025/yang2/index.html
    Eine der Hauptfiguren ist Fern und benutzt fast ausschließlich den verbreiteten Angriffszauber Zoltraak
    [1] https://en.wikipedia.org/wiki/Frieren

  • Meine Güte, eine von mir geschriebene Game-Boy-Lebensspiel-Implementierung ist in einem der Gewinnerbeiträge enthalten!

    • Nachdem ich den Emulator gebaut hatte, habe ich GitHub nach Spielen durchsucht, die innerhalb der 32-KB-Beschränkung laufen könnten. Ich habe deins gefunden, danke dafür :-) Im ./try.sh-Skript habe ich eine Option eingebaut, mit der Nutzer es von GitHub herunterladen und testen können

  • Im Jahr 2000 hatte ich mein erstes Vorstellungsgespräch für ein Praktikum, für eine Stelle in einem Team von C-Programmierern. Die Interviewer zeigten mir einen früheren Gewinnerbeitrag und verließen den Raum mit der Bitte, den Code zu reviewen. Etwa fünf Minuten später kamen sie zurück und fragten
    – Und?
    – Entschuldigung, ich habe wohl Ihre Zeit verschwendet. Ich verstehe überhaupt nichts davon
    Daraufhin brachen alle in Gelächter aus und meinten, wir könnten mit dem Einstellungsprozess beginnen
    Ich frage mich, ob man Praktikanten heute noch so aufzieht. Wenn ich an mein damaliges überfordertes Ich denke, muss ich immer noch lachen

  • Ooooh! Die IOCCC ist zurück!
    Viel Liebe an die Organisatoren <3 <3 <3 Danke, dass ihr die IOCCC am Leben haltet, und hoffentlich verschwindet sie nie wieder

  • Moment, ich verstehe das nicht ganz
    Der Obfuscated C Code Contest geht, aber Capture the Flag nicht? Wegen AI?
    https://twit.tv/posts/tech/ai-disrupts-capture-flag-what-mea...

    • Capture the Flag hat ein klares Ziel, der Obfuscated C Contest aber nicht. Dass AI in zielorientierten Wettbewerben Fortschritte macht, ist nachvollziehbar, aber bei einem offenen Wettbewerb mit künstlerischem Gespür weiß ich nicht, was überhaupt als Fortschritt gelten soll
      Falls die Frage ist: "Kann man nicht eine clevere Idee haben und dann die AI bitten, sie innerhalb der IOCCC-Beschränkungen umzusetzen?", dann glaube ich, dass die heutigen AI-Tools das noch nicht auf einem Niveau schaffen, das menschliche Juroren als wertvoll ansehen würden