第29回 IOCCC 2025 受賞作発表

 (ioccc.org)
3 ポイント 投稿者 GN⁺ 8 시간 전 | 1件のコメント | WhatsAppで共有
  • International Obfuscated C Code Contest（国際難読化Cコードコンテスト）は、最も創造的で芸術的でありながら読みづらい「難読化（Obfuscated）」Cコードを競うコンピュータプログラミング大会
  • 2020〜2024年の空白期間後、2年連続で開催された大会の2回目で、応募数は前年と同程度だったものの、応募作の規模と品質は過去最高級の水準を維持
  • Yusuke Endoh、Nick Craig-Wood、Don Yang の3名がそれぞれ3作品を受賞し、ハットトリックを達成、さらに Taiwan 出身の新規受賞者も登場
  • Subleqコンピュータ、GameBoyエミュレータ、patch/diffクワインなど多彩な受賞作が選ばれ、各受賞作には Fun challenge も導入
  • 受賞作発表は Our Favorite Universe YouTubeチャンネルのライブショーで行われ、次回の IOCCC30 は2026年末に開催予定

出発点

  • 2025年のIOCCC受賞エントリへのリンクは、このページ下部の受賞作一覧で確認可能
  • 各受賞エントリの index.html には、受賞プログラムをコンパイルして実行するために必要な情報の大半が記載されている
  • 受賞ソースコードを読みながら動作の仕組みを把握し、より詳しい内容は作者の説明で確認できる
  • 今年の大会の全受賞作は、圧縮tarball 形式でダウンロード可能

今回のコンテストに関する一般的な注記

  • IOCCC29 の応募数と応募品質は、歴史的最高水準に近い
  • IOCCC28 は4年間の空白後の開催だったため、参加者が応募作を磨く時間を持てた結果、記録的な応募数と通常より高い応募品質につながったのではないかと推測されている
  • IOCCC29 は2020〜2024年の空白期間後、2年連続開催となる2回目だったが、応募数は前年大会とほぼ同程度で、全体の応募品質も高水準を維持した
  • IOCCC28終了時点から、新規応募の締切、審査手順、受賞作の選定、Webサイト更新、Our Favorite Universe ライブショー制作の手順までを注意深く文書化した
  • 文書化には追加の時間と労力が必要だったが、その結果、IOCCCの運営方法全般の改善が達成された
  • IOCCC29受賞作の発表が Our Favorite Universe YouTubeチャンネルで行われてから数日後、メインショーの録画を個別セグメントに分割する予定
  • 各受賞エントリの index.html 上部付近には、新しい Award presentation セクションとYouTubeセグメントへのリンクが追加される予定

  • 楽しいチャレンジ課題について

    • 今年の受賞作には、「Judges’ remarks」セクションの下に楽しいチャレンジ課題が追加されている
    • 特定の受賞作の機能を把握したうえで、そのチャレンジ課題に挑戦することを推奨
    • 課題によって難易度は異なり、場合によっては prog.c または関連ファイルの代替版の作成が求められる
    • 特定の項目について説明文を書くことが求められる課題もある
    • 特定受賞作の「A fun challenge」セクションでチャレンジ課題が still open 状態であれば、GitHub pull request の提出で貢献できる
    • チャレンジ課題が締め切られていても、より良い解法があると判断した場合は GitHub pull request を提出可能
    • IOCCC Judges がそれをより良い解法だと認めれば、検討対象となる
    • 受賞作の楽しいチャレンジ課題に対してさらに優れた改善案があるなら、IOCCC Judges の検討のため GitHub pull request を提出できる

  • 今回のコンテストのルールとガイドライン

    • 今回の大会に適用された最終ルールは 2025 rules バージョン 29.15 2025-12-02
    • 今回の大会に適用された最終ガイドラインは 2025 guidelines バージョン 29.08 2025-12-02
    • IOCCC29 のルールとガイドラインは前回大会と比べて大幅に改訂された
    • 複数のボランティアが、IOCCC Judges に対して有用な編集、文面改訂、統合、全体構成の改善を提供した

  • 次のコンテストに向けて

    • IOCCC30 は2026年末ごろの開幕を予定
    • IOCCC30 も同様の期間で実施され、2027年第1四半期末ごろに終了する計画
    • IOCCC30開幕に必要な作業を進める中で、IOCCC29の締切時と同様に内部手順の文書化を行う予定
    • IOCCC29 受賞作公開からおよそ2〜3週間が経ち、2025ディレクトリツリー に対する初期の pull requests の一部を処理した後、IOCCC Judges は IOCCC vacation を予定している
    • IOCCC28受賞作公開後にも IOCCC vacation の予定はあったが、mkiocccentry repo のバグ修正と改善対応に多くの時間を要し、リポジトリが安定したころにはIOCCC29開幕の時期に達していた
    • 今回は post-IOCCC29 の IOCCC vacation 終了後に mkiocccentry repo PRs へ取り組む予定
    広告

一部受賞作に関する注記

  • 審査ラウンド最終セットの最終ラウンドに進んだ応募作について紹介文案を作成する過程で、一部の応募作は最終ラウンドの最後の段階で選外となった
  • 残った複数のエントリに対しては、さらなる称賛と評価の上昇があった
  • 受賞作の作者は従来の受賞者地域からも出ており、IOCCC29 では新たな地域として Taiwan 出身の jingp49 も参加した
  • 3人の作者がそれぞれ3エントリで受賞し、Hat trick) の Hat-tricks を構成した
  • 注目すべきIOCCC29受賞作の一部は次のとおり
  • 上記一覧は、IOCCC29の数多くの優れた受賞作の一部にすぎない

  • 受賞に至らなかった一部応募作に関する注記

    • 最終選考に非常に近づきながら受賞には至らなかった優れた応募作も多数存在した
    • 各作者がエントリに注いだ努力は高く評価されるが、努力だけを基準に授賞することはできない
    • IOCCC29 に応募したものの受賞しなかったコードは、磨き直したうえで IOCCC30 に再応募できる
    • IOCCC29 の受賞作の中には、前回大会で受賞しなかったコードを改良した版が少なくとも1つ以上ある

  • 今年受賞しなかった参加者への励まし

    • 今年のIOCCC応募作には多大な努力が注がれていたが、すべての応募作に賞を与えることはできない
    • すべての応募作に賞を与えてしまうと、最良で受賞に値すると判断された応募作の意味が失われてしまう
    • 最終ラウンドに進んだ応募作が受賞作に十分匹敵する出来であっても、似ていてわずかに優れた別の応募作に及ばないことがある
    • そのようなケースだと考えられる応募作については、次回IOCCCに改良版を応募することが勧められている
    • 複数回の修正応募を経て受賞作レベルに到達した応募作も存在する
    • 次回IOCCCでは、まったく異なるタイプの応募作に挑戦することもできる
    • 次回IOCCCに非受賞エントリの改良版を再応募する予定がない場合は、それを公開することも可能
    広告

受賞作のコンパイルと実行

2025年第29回 IOCCC 受賞作

関連記事

1件のコメント

 
GN⁺ 8 시간 전
Hacker Newsの意見

  • GameBoyエミュレーター のコードがGameBoyの形にまで見える。思わず遅い拍手が出るレベルで狂っていて、個人的には今回の応募作の中でいちばん気に入った
    https://github.com/ioccc-src/winner/blob/master/2025/ncw1/pr...
    作者のNick Craig-Woodは rclone を作った人でもある

    • 楽しんでもらえてうれしい :-) どうやって作られたのか見たければ、元のコードはこちら
      https://github.com/ncw/ioccc-gameboy
      そこには難読化していない版もだいたい入っている。実際に作業したのはそちらで、その後プログラムで変数名をすべて潰し、GameBoyの形に合うよう圧縮した
      応募作の サイズ制限 がいちばん大変だった。IOCCCの応募作は空白を除いて2503文字までで、コード全体のサイズは4KBだが、その中にZ80プロセッサーとGameBoyハードウェアのエミュレーターを入れるのは本当に小さい
      最初はCで完全なGameBoyエミュレーターを書き、空白を除いて約6000文字から始まった。その後2503文字制限に収めるために約100時間を費やし、しばらくのあいだ本当に入るのか確信が持てなかった
      目標はTetrisを動かすことにした。Tetrisは比較的単純なゲームなので、Z80エミュレーターのhalf carryフラグや、GameBoyエミュレーションのウィンドウ機能のような不要な機能を削った。またCコードをひどいほど酷使し、implicit intで二度と忘れられないようなこともした。IOCCCのルールチェッカーがCプログラムで実装されていたので、それをリバースエンジニアリングして抜け穴を探すのにも時間を使った。特定の演算子がトークン1個としてしか数えられないことを見つけたのは特に有用だった
      十分に小さくなった後は、実行するゲームも入れなければならなかった。Z80アセンブリで書いたテストプログラム、アセンブリで作った円周率計算機、gbdk-2020でCから作った3D三目並べ、Cで作ったチェスプログラムの4つを作った。かなり多くのオープンソースゲームがこのエミュレーターで動くことも分かったので、可能なときはダウンローダーも追加した。意外にも BCD演算 を使うゲームは多くなかった
      楽しいプロジェクトだった
    • https://github.com/ncw/ccforth
      https://github.com/ncw/ccforth/tree/master/examples/gameboy
    • すごい！ これを見ながら、自分は CSSとPHP なんかをいじっているのかと思ってしまう
    • コードを絵のように見せるのは、難読化プログラミングコンテスト ではかなりよく使われるクリシェだ

  • 私がいちばん気に入ったのは、Linux と Doom を実行できる 366バイトのCプログラムエミュレータ だ [0]
    この仮想マシンは OISC、つまり 単一命令コンピュータ を実装している [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...

    • ここ数週間、Linux/amd64 アセンブリにコンパイルされる自作のシンプルなプログラミング言語を作っていた
      ファイルを開く処理、シェルコマンドの実行、strstr や strcpy のような標準ライブラリルーチンを大量に書くこともできたし、正直、学習の過程で不要なものまで実装してしまった。たとえば print(getenv("HOME")) は動く。だがすぐに、テスト用かつ見せびらかし用の サンプルプログラム が必要だと気づいた
      そこで当然、最初に実装したまともなプログラムは brainfuck インタプリタだった。そのおかげで私の言語は今や間接的にチューリング完全になった
      初期バージョンでは有名な mandelbrot プログラムの出力を出すのに 9 分かかったので、いろいろ最適化を行い、その後 switch/case 文のサポートも加えて速度を上げた。今では同じ出力を 2 分で生成できるので、まだ改善の余地はあるが、かなり前進した
      自分の言語の中に別の言語を実装するという 反則っぽいやり方 がとても満足感を与えてくれた。もちろん、すべて遊びと学習のためであって、私自身を含め、誰かに本気で使ってほしくて作ったものではない
      https://github.com/skx/s-lang
    • おお! しかもチューリング完全な SUBLEQ の変種 をとても興味深く実装している

      この VM は OISC、すなわち One Instruction Set Computer を実装している。この命令は 3 つの符号付き 32 ビットオペランド a, b, c を受け取り、メモリ m[] 上で次のようにプログラムを実行する:
      1 PC(program counter) は 0 から始まる
      2 次の命令、すなわち符号付き 32 ビットオペランド a, b, c を読み込む
      3 いずれかのオペランドで下位ビットがセットされていれば、そのビットを取り除き、そのオペランドを m[operand]、つまりそのアドレスのデリファレンス値に置き換える
      4 m[b] = m[b] - m[a] に設定する
      5 m[b] が 0 以下なら PC を c に設定し、そうでなければ PC を 3 ワード進める
      6 手順 2 に戻る

    • このアイデアは気に入っている気がするが、リンク先の Eternal Software Initiative [1] は少し混乱する。これをデコードする命令の説明が複数バージョンあり、互いに食い違っている
      こちらには Set m[b] = m[b] - m[a] と書かれている
      そのあと GitHub の参照実装 [2] に飛び、そこではナプキンメモ [3] だけ見ればよいとされている。そこでは読み取った値をすべて 4 で割る方式になっており、参照実装 [4] もそれを裏づけている。だが、なぜ 2 ではなく 4 を選んだのかは明確ではない。ビットを 1 つ無駄にしているように見える。このビットが必要だったのか、それとも将来の拡張のために予約されているのか気になる
      元の実装は 4 で割っておらず、あとから追加されたように見えるが、LLVM のコード生成を少し楽にする以外に、なぜ必要だったのか分からない。4 で割らないと説明されたシステムが成立しないのか確かめるには、かなり多くの例を追ってみる必要がありそうだ。おそらく偶数アドレスにしかアクセスできず、PC は毎回 3 ずつ増えるので、コード位置を参照するのは確かに厄介だっただろう
      参照実装では位置 64 にアクセスすると魔法のような動作をし、位置 64〜67 を現在時刻で上書きする。ナプキンの説明には出てくるが、メインページの説明にはない
      どちらの説明でも魔法の -1 アドレスに触れているので、実装依存の UTC 時計も、自由に使えるメモリを壊す代わりに、負のアドレスで実装しなかったのは奇妙だ
      どちらの説明でも定期タイマー割り込みの処理にも言及しているが、これも惜しい。アドレス 0 を割り込みハンドラの位置として、1 を保存された PC として再利用するため、プログラム開始直後に初期エントリポイントである位置 0 を上書きしなければならない
      [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
    • ダウンロードしてビルドしてみたが、今まで見た中で 最も印象的なもの だと自信を持って言える
    • 動画はこちら
      https://www.youtube.com/live/MoWCwZx1Swc?si=eIOlRsKWNKRVRZeB...

  • 気になっている人がいるかもしれないので: IOCCC はガイドラインで LLM の使用を明示的に許可している
    "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."

    • 私は非AI派だが、この件は興味深い。特にオンラインには 難読化 C コード があまり多くなく、LLM が実際のコードから意図を推論するのも難しいからだ。LLM の支援を受けた応募作を見たことがある人がいるのか気になる
      逆もまた興味深い。LLM は難読化されたコードの機能をどれくらいうまく当てられるのだろうか?
    • これは主に審査員に影響する。粗悪なコードが大量に流れ込む可能性を自ら開くことになるが、大会の性格上、審査員は 興味深いコード と低品質なコードを非常によく見分けられる気がする
      IOCCC が機械の助けで作られたかもしれないコードを受け入れるのは良いことだと思う。そのおかげで、純粋な手作業の優勝作の価値がいっそう大きく見える
    • では LLM 体操大会 になったということか?
    • 「ツール」に AI が含まれるなら、ルール 7 は自己矛盾になる
      https://www.ioccc.org/2025/rules.html
      ここで言っているのはカスタムのコード生成器を指しているように見える。「豊かな歴史」と明示していて、AI が存在しなかった時代まで含む表現なのに、なぜそれが AI を意味すると考えるのか分からない

  • ウェブサイト自体も 難読化 されていて、C ソースを見つけるのがまったく簡単ではない

    • 直接 https://www.ioccc.org/2025/#inventory に行けばよい
    • 本当に探しにくい。大会が何なのか把握できず、すでに知っていることを前提に作られているように見える
    • 最初の文が優勝作一覧セクションへのリンクになっていて、各優勝作の右上に C code リンクがある

  • Underhanded C Contest が復活してほしい。Obfuscated C の参加者をけなしたいわけではないが、私にはあちらのほうがずっと面白かった

  • ここに Frieren [1] への参照がある!
    https://www.ioccc.org/2025/yang2/index.html
    主人公の一人が Fern で、ほとんど全面的にありふれた攻撃魔法 Zoltraak を使う
    [1] https://en.wikipedia.org/wiki/Frieren

  • なんてことだ、私が作った Game Boy のライフゲーム 実装が優勝作の 1 つに入っている!

    • エミュレータを作ったあと、32KB の制限内で実行できるゲームを探そうとして GitHub を漁った。あなたのものを見つけたので感謝している :-) ./try.sh スクリプトには、ユーザーが GitHub からダウンロードしてテストできるオプションを入れておいた

  • 2000 年に最初のインターン面接を受けたが、C プログラマのチームに加わるポジションだった。面接官たちは昔の優勝作の 1 つを見せて、コードレビューをしてみてくれと言って部屋を出ていった。5 分ほどして戻ってきて、こう聞いた
    – それで?
    – すみません、時間を無駄にさせてしまいました。まったく理解できません
    すると全員が笑い出し、採用手続き を始めようと言った
    今でもインターンにこんないたずらをするのだろうか。当時うろたえていた自分を思い出すと、今でも笑ってしまう

  • おおお! IOCCC が帰ってきたのか!
    主催者たちに愛を送る <3 <3 <3 IOCCC を続けてくれてありがとう、そしてもう二度と消えないでほしい

  • ちょっと待って、少し分からない
    Obfuscated C Code Contest はよくて、Capture the Flag はだめだということ? AI のせいで?
    https://twit.tv/posts/tech/ai-disrupts-capture-flag-what-mea...

    • Capture the Flag には明確な目標があるが、Obfuscated C Contest にはそれがない。目標指向の大会で AI が進歩するのは理解できるが、芸術的センス が入るオープンエンドな大会で、何を進歩と見なすべきなのかはよく分からない
      「賢いアイデアを思いついたあと、AI に IOCCC の制約に合わせて実装してもらえるのでは?」と聞いているのなら、現在の AI ツールはまだ、人間の審査員が価値があると見るレベルでそれをやり切れてはいないと思う