29. IOCCC 2025 kazananları açıklandı

 (ioccc.org)
3 puan yazan GN⁺ 8 시간 전 | 1 yorum | WhatsApp'ta paylaş
  • International Obfuscated C Code Contest (Uluslararası Obfuscated C Kod Yarışması), en yaratıcı, en sanatsal ve okunması en zor 'obfuscated' C kodunu yarıştıran bir bilgisayar programlama yarışmasıdır
  • 2020~2024 arasındaki aradan sonra art arda ikinci kez düzenlenen yarışmada, başvuru sayısı geçen yılla benzer olsa da başvuruların ölçeği ve kalitesi tarihî düzeyini korudu
  • Yusuke Endoh, Nick Craig-Wood ve Don Yang üçer ödüllü eser çıkararak birer hat-trick yaptı; ayrıca Taiwan çıkışlı yeni bir kazanan da ortaya çıktı
  • Subleq bilgisayarı, GameBoy emülatörü, patch/diff quine gibi çeşitli kazanan eserler seçildi ve her ödüllü çalışmaya Fun challenge eklendi
  • Kazananlar, Our Favorite Universe YouTube kanalı canlı yayınıyla duyuruldu; bir sonraki IOCCC30'un 2026 sonlarında yapılması planlanıyor

Başlangıç noktası

  • 2025 ödüllü IOCCC girdilerine ait bağlantılar, sayfanın altındaki kazananlar listesinde görülebilir
  • Her ödüllü girdinin index.html dosyası, ödüllü programı derlemek ve çalıştırmak için gereken bilgilerin büyük bölümünü sunar
  • Ödüllü kaynak kodu okuyarak nasıl çalıştığını anlayabilir, daha ayrıntılı bilgi için yazarın açıklamasına bakabilirsiniz
  • Bu yılki yarışmanın tüm kazananları sıkıştırılmış tarball olarak indirilebilir

Bu yarışmaya dair genel notlar

  • IOCCC29'daki başvuru hacmi ve başvuru kalitesi, tarihî zirveye yakın bir düzeydeydi
  • IOCCC28, 4 yıllık aradan sonra düzenlendiği için katılımcıların çalışmalarını cilalamaya vakti olduğu ve bunun da rekor sayıda başvuru ile normalden yüksek kaliteyi getirdiği yönünde tahminlere konu olmuştu
  • IOCCC29, 2020~2024 arasındaki boşluğun ardından üst üste yapılan ikinci yarışma olmasına rağmen, başvuru sayısı önceki yılla benzer kaldı ve genel kalite seviyesi de yüksekliğini korudu
  • IOCCC28'in bitiminden itibaren yeni başvuru kapanışı, jüri süreci, kazanan seçimi, web sitesi güncellemesi ve Our Favorite Universe canlı yayınının hazırlanma süreci dikkatle belgelendi
  • Bu belgeleme ek zaman ve emek gerektirdi, ancak sonuç olarak IOCCC'nin işleyişinin genelinde iyileştirme sağlandı
  • IOCCC29 kazananlarının Our Favorite Universe YouTube kanalında duyurulmasından birkaç gün sonra, ana program kaydı ayrı bölümlere ayrılacak
  • Her ödüllü girdinin index.html dosyasının üst tarafına yeni bir Award presentation bölümü ve ilgili YouTube bölüm bağlantısı eklenecek

  • Eğlenceli meydan okuma bilgisi

    • Bu yılın ödüllü çalışmalarına, “Judges’ remarks” bölümünün altında eğlenceli meydan okumalar eklendi
    • Belirli bir ödüllü çalışmanın ne yaptığını anladıktan sonra ilgili meydan okumayı denemeniz önerilir
    • Bazı görevler diğerlerinden daha kolaydır; kimi durumlarda prog.c ya da ilgili dosyaların alternatif sürümünü üretmeniz istenir
    • Bazı görevler ise belirli bir öğe hakkında açıklama yazmanızı ister
    • Belirli bir kazananın “A fun challenge” bölümündeki görev hâlâ still open durumundaysa, GitHub pull request göndererek katkıda bulunabilirsiniz
    • Meydan okuma kapanmış olsa bile daha iyi bir çözümünüz olduğunu düşünüyorsanız yine GitHub pull request gönderebilirsiniz
    • IOCCC Judges bunun daha iyi bir çözüm olduğuna katılırsa değerlendirmeye alınır
    • Ödüllü bir çalışmanın eğlenceli meydan okuması için daha iyi bir geliştirme öneriniz varsa, IOCCC Judges incelemesi için GitHub pull request gönderebilirsiniz

  • Bu yarışmanın kuralları ve yönergeleri

    • Bu yarışmada uygulanan son kurallar, 2025 rules sürüm 29.15 2025-12-02 oldu
    • Bu yarışmada uygulanan son yönergeler, 2025 guidelines sürüm 29.08 2025-12-02 oldu
    • IOCCC29'un kuralları ve yönergeleri önceki yarışmaya kıyasla büyük ölçüde yeniden düzenlendi
    • Birden fazla gönüllü, IOCCC Judges için faydalı düzenlemeler, ifade revizyonları, birleştirmeler ve genel yapı iyileştirmeleri sağladı

  • Bir sonraki yarışmaya doğru

    • IOCCC30'un 2026 sonlarına doğru başlaması planlanıyor
    • IOCCC30'un benzer bir süre boyunca devam edip 2027'nin ilk çeyreğinin sonlarına doğru bitmesi planlanıyor
    • IOCCC30'un açılışı için gerekli işleri yürütürken, IOCCC29 kapanışında olduğu gibi iç süreçlerin yeniden belgelenmesi planlanıyor
    • IOCCC29 kazananları yayımlandıktan yaklaşık 2~3 hafta sonra ve 2025 directory tree için ilk pull requests taleplerinden bazıları işlendiğinde, IOCCC Judges bir IOCCC vacation yapmayı planlıyor
    • IOCCC28 kazananları açıklandıktan sonra da bir IOCCC vacation planlanmıştı; ancak mkiocccentry repo'sundaki hata düzeltmeleri ve iyileştirmeler çok zaman aldığı için depo istikrara kavuştuğunda IOCCC29'un açılış zamanı gelmişti
    • Bu kez, post-IOCCC29 IOCCC vacation sona erdikten sonra mkiocccentry repo PRs üzerinde çalışılması planlanıyor
    Reklam

Bazı ödüllü çalışmalara dair notlar

  • Jüri turlarının son setinin nihai turuna kalan başvurular için olası yazılar hazırlanırken, bazı başvurular son turun en son aşamasında elendi
  • Geriye kalan çeşitli girdiler için ek hayranlık ve daha yüksek değerlendirme oluştu
  • Kazanan yazarlar, önceki kazanan yazar bölgelerinden geldiği gibi, IOCCC29'da yeni bir bölge olan Taiwan çıkışlı jingp49 da yer aldı
  • Üç yazarın da üçer girdiyle ödül alması, Hat trick) içinde Hat-tricks oluşturdu
  • IOCCC29'un dikkat çeken bazı ödüllü çalışmaları şunlar oldu
  • Yukarıdaki liste, IOCCC29'daki çok sayıdaki olağanüstü ödüllü çalışmadan yalnızca bir kısmını içeriyor

  • Ödül alamayan bazı başvurulara dair notlar

    • Son seçime çok yaklaşmasına rağmen ödül alamayan çok sayıda harika başvuru vardı
    • Her yazarın girdisine kattığı emek takdir edilse de, ödüller yalnızca emeğe göre verilemez
    • IOCCC29'a gönderilip ödül alamayan kodlar, gözden geçirilip iyileştirildikten sonra IOCCC30 için yeniden gönderilebilir
    • IOCCC29 kazananlarından en az biri, önceki yarışmada ödül alamamış bir kodun geliştirilmiş sürümüdür

  • Bu yıl kazanamayan katılımcılara teşvik

    • Bu yılki IOCCC başvurularına çok emek verildi, ancak her başvuruya ödül vermek mümkün değil
    • Her başvuruya ödül verilmesi, en iyi kabul edilen ve ödülü gerçekten hak eden başvuruların anlamını azaltır
    • Final turuna kalan bir başvuru kazanmaya yetecek kadar iyi olsa bile, benzer ama biraz daha iyi bir başvuruya yenilebilir
    • Böyle olduğu düşünülen başvurular için bir sonraki IOCCC'ye geliştirilmiş sürüm göndermek önerilir
    • Birkaç kez revize edilip yeniden gönderildikten sonra kazanan düzeyine ulaşan başvurular da vardır
    • Bir sonraki IOCCC için tamamen farklı türde bir başvuru denemek de mümkündür
    • Bir sonraki IOCCC'ye ödül alamayan bir girdiyi geliştirip yeniden göndermeyi planlamıyorsanız, onu yayımlayabilirsiniz
    Reklam

Ödüllü çalışmaları derleme ve çalıştırma

2025 29. IOCCC kazananları

İlgili okumalar

1 yorum

 
GN⁺ 8 시간 전
Hacker News yorumları

  • GameBoy emülatörü kodu, GameBoy şeklinde bile görünüyor. Yavaş alkışı hak edecek kadar çılgınca ve kişisel olarak bu yılki işler arasında en çok beğendiğim bu
    https://github.com/ioccc-src/winner/blob/master/2025/ncw1/pr...
    Yazarı Nick Craig-Wood, rclone'u yapan kişi

    • Beğenerek bakmana sevindim :-) Nasıl yapıldığını görmek istersen orijinali burada
      https://github.com/ncw/ioccc-gameboy
      Orada kabaca obfuscate edilmemiş bir sürüm de var. Asıl üzerinde çalıştığım taraf oydu; sonrasında bir programla tüm değişken adlarını ezip GameBoy şekline uyacak şekilde sıkıştırdım
      Yarışmadaki boyut sınırı en zor kısımdı. IOCCC başvurularında boşluk hariç 2503 karaktere izin veriliyor ve toplam kod boyutu 4KB, ama içine Z80 işlemcisiyle GameBoy donanım emülatörünü sığdırmak gerçekten çok küçük bir alan
      Başta C ile tam bir GameBoy emülatörü yazdım ve boşluk hariç yaklaşık 6000 karakterden başladım. Sonra bunu 2503 karakter sınırına indirmek için yaklaşık 100 saat harcadım ve bir süre sığıp sığmayacağından emin değildim
      Hedefi Tetris'i çalıştırmak olarak belirledim. Tetris nispeten basit bir oyun olduğu için Z80 emülatöründeki half carry bayrağı ya da GameBoy emülasyonundaki windowing sistemi gibi gereksiz özellikleri çıkardım. Ayrıca C kodunu korkunç derecede zorladım ve implicit int ile bir daha unutamayacağım şeyler yaptım. IOCCC kural denetleyicisi C programı olarak yazılmış olduğundan, bunu tersine mühendislikle inceleyip açıklarını bulmaya da zaman harcadım. Özellikle bazı operatörlerin yalnızca tek bir token olarak sayıldığını keşfetmem çok işe yaradı
      Yeterince küçüldükten sonra içine çalıştıracak oyunlar da koymam gerekiyordu. Z80 assembly ile yazılmış bir test programı, assembly ile yapılmış bir pi hesaplayıcısı, gbdk-2020 ile C'de yapılmış 3D tic-tac-toe ve C ile yazılmış bir satranç programı olmak üzere dört tane hazırladım. Ayrıca epey açık kaynak oyunların da bu emülatörde çalıştığını fark ettim; mümkün olduğunda bir indirici de ekledim. Şaşırtıcı biçimde BCD aritmetiği kullanan oyun çok fazla değildi
      Eğlenceli bir projeydi
    • https://github.com/ncw/ccforth
      https://github.com/ncw/ccforth/tree/master/examples/gameboy
    • Harika! Ben de burada oturmuş CSS ve PHP ile uğraşıyorum
    • Kodu resim gibi göstermek, obfuscated programming contest'lerde oldukça sık kullanılan bir klişe

  • En çok hoşuma giden şey, Linux ve Doom çalıştırabilen 366 baytlık bir C programı emülatörü oldu [0]
    Bu sanal makine, OISC yani tek komutlu bilgisayar uyguluyor [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...

    • Son birkaç haftadır Linux/amd64 assembly'ye derlenen basit bir programlama dilim üzerinde çalışıyordum
      Dosya açma, shell komutları çalıştırma, strstr, strcpy gibi standart kütüphane rutinlerinden bir sürü yazabilirdim ve açıkçası öğrenme sürecinde gerekli olmayan şeyleri de uyguladım. Örneğin print(getenv("HOME")) çalışıyor. Ama kısa süre sonra test ve gösteriş için örnek programlara ihtiyacım olduğunu fark ettim
      Bu yüzden doğal olarak ilk uyguladığım gerçek program bir brainfuck yorumlayıcısı oldu. Böylece dilim artık dolaylı olarak Turing-complete
      İlk sürüm, meşhur mandelbrot programının çıktısını üretmek için 9 dakika harcıyordu; ben de çeşitli optimizasyonlar yaptım ve sonra hız kazanmak için switch/case deyimi desteği ekledim. Artık aynı çıktıyı 2 dakikada üretebiliyor, yani hâlâ iyileştirme payı var ama epey ilerleme de kaydedildi
      Kendi dilimin içinde başka bir dili uygulayan bu biraz hileli yöntem bana çok tatmin edici geldi. Tabii her şey eğlence ve öğrenme amaçlı; benim dâhil kimsenin bunu ciddi ciddi kullanması için yapılmış değil
      https://github.com/skx/s-lang
    • Vay canına! Ayrıca Turing-complete bir SUBLEQ varyantını da oldukça ilginç şekilde uygulamış

      Bu VM, OISC yani One Instruction Set Computer uygular. Bu komut, işaretli 32 bitlik üç operand a, b, c alır ve programı bellek m[] üzerinde şu şekilde çalıştırır:
      1 PC (program counter) 0'dan başlar
      2 Sonraki komutu, yani işaretli 32 bitlik operandlar a, b, c'yi getir
      3 Herhangi bir operandın alt biti set ise bu biti temizle ve ilgili operandı m[operand], yani o adresteki dereference edilmiş değer ile değiştir
      4 m[b] = m[b] - m[a] olarak ayarla
      5 m[b] 0 veya daha küçükse PC'yi c yap, değilse PC'yi 3 word artır
      6 2. adıma dön

    • Fikri beğenmiş gibiyim ama bağlantı verilen Eternal Software Initiative [1] biraz kafa karıştırıcı. Bunu decode eden komut açıklamasının birden fazla sürümü var ve birbirleriyle çelişiyor
      Burada m[b] = m[b] - m[a] olarak ayarla deniyor
      Sonra GitHub'daki referans implementasyona [2] bağlanıyor; orada ise yalnızca peçete notunun [3] önemli olduğu söyleniyor. Bu sürümde okunan tüm değerler 4'e bölünüyor ve referans implementasyon [4] da bunu destekliyor. Ama neden 2 yerine 4 seçildiği net değil. Sanki bir bit boşa harcanıyormuş gibi görünüyor. Bu bitin gerekli olup olmadığını ya da gelecekteki genişletmeler için mi ayrıldığını merak ediyorum
      Orijinal implementasyon 4'e bölmüyordu ve bu sonradan eklenmiş gibi görünüyor; ama LLVM kod üretimini biraz kolaylaştırması dışında neden gerektiğini anlayamadım. 4'e bölmeden anlatılan sistemin imkânsız olup olmadığını doğrulamak için herhalde epey örnek üzerinden gitmek gerekir. Muhtemelen sadece çift adreslere erişilebilmesi ve PC'nin her seferinde 3 artması yüzünden kod konumlarına referans vermek gerçekten zahmetli olurdu
      Referans implementasyon, 64. konuma erişildiğinde sihirli biçimde davranıp 64-67 konumlarını geçerli saat ile üzerine yazıyor. Peçete açıklamasında var ama ana sayfa açıklamasında yok
      Her iki açıklama da sihirli -1 adresinden söz ediyor; bu yüzden implementasyona bağlı UTC saatinin, serbestçe kullanılabilecek belleği bozmak yerine neden negatif bir adresle uygulanmadığı garip geliyor
      Her iki açıklama da periyodik zamanlayıcı kesmesi sürecinden söz ediyor ve bu da biraz talihsiz. Çünkü 0 adresi kesme işleyicisinin konumu, 1 adresi ise kaydedilmiş PC olarak yeniden kullanılıyor; dolayısıyla program başlar başlamaz başlangıç giriş noktası olan 0. konumun üzerine yazılması gerekiyor
      [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
    • İndirip derledim; şimdiye kadar gördüklerim arasında en etkileyicisi olduğunu rahatlıkla söyleyebilirim
    • Video burada
      https://www.youtube.com/live/MoWCwZx1Swc?si=eIOlRsKWNKRVRZeB...

  • Merak eden olur diye: IOCCC, yönergelerinde LLM kullanımına açıkça izin veriyor
    "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."

    • Ben AI karşıtı tarafta değilim ama bu durumda ilginç geliyor. Özellikle internette obfuscated C code çok fazla olmadığı ve LLM'lerin gerçek koddan niyeti çıkarması da zor olduğu için. LLM yardımı almış bir başvuru görüp görmediğimi merak ediyorum
      Tersi de ilginç. LLM, obfuscated edilmiş kodun ne yaptığını ne kadar iyi tahmin edebilir?
    • Bu daha çok jüriyi etkiliyor. Kötü kod seline kapıyı kendi elleriyle açmış oluyorlar ama yarışmanın doğası gereği jüri üyeleri ilginç kod ile düşük kaliteli kodu oldukça iyi ayırt eder gibi geliyor
      IOCCC'nin makine yardımıyla yapılmış olabilecek kodları kabul etmesini iyi buluyorum. Bu sayede tamamen el emeğiyle yapılmış kazananların değeri daha da artıyor gibi görünüyor
    • O zaman bu bir LLM jimnastiği yarışması mı oldu?
    • Eğer AI "araçlara" dahilse, kural 7 kendi içinde çelişkili hale geliyor
      https://www.ioccc.org/2025/rules.html
      Burada kastedilenin özel amaçlı kod üreticileri olduğunu düşünüyorum. Açıkça "zengin bir tarih" deniyor; AI'ın olmadığı dönemleri de kapsayan bir ifadeyse neden bunun AI anlamına geldiğini düşünelim, emin değilim

  • Web sitesinin kendisi de obfuscated olduğu için C kaynak kodunu bulmak hiç kolay değil

    • Doğrudan https://www.ioccc.org/2025/#inventory adresine gidebilirsiniz
    • Gezinmesi gerçekten zor. Yarışmanın ne olduğunu anlamak kolay değil ve sanki zaten biliyormuşsunuz varsayımıyla yapılmış gibi duruyor
    • İlk cümle kazananlar listesi bölümüne gidiyor ve her kazananın sağ üst köşesinde C code bağlantısı var

  • Underhanded C Contest'in geri dönmesini isterdim. Obfuscated C katılımcılarını küçümsemek için söylemiyorum ama öteki bana çok daha ilginç geliyordu

  • Burada bir Frieren [1] referansı var!
    https://www.ioccc.org/2025/yang2/index.html
    Ana karakterlerden birinin adı Fern ve neredeyse tamamen yaygın saldırı büyüsü Zoltraak'ı kullanıyor
    [1] https://en.wikipedia.org/wiki/Frieren

  • Aman tanrım, benim yaptığım Game Boy Yaşam Oyunu uygulaması kazananlardan birinin içinde yer alıyor!

    • Emülatörü yaptıktan sonra 32KB sınırı içinde çalıştırılabilecek oyunlar aramak için GitHub'ı taradım. Seninkini buldum, teşekkürler :-) Kullanıcının GitHub'dan indirip deneyebilmesi için ./try.sh betiğine bir seçenek ekledim

  • 2000 yılında ilk staj mülakatıma girmiştim; C programcılarından oluşan bir ekibe katılacaktım. Mülakatçılar bana eski kazananlardan birini gösterip kodu incelememi söyleyerek odadan çıktılar. Yaklaşık 5 dakika sonra geri dönüp sordular
    – Eee?
    – Üzgünüm, vaktinizi boşa harcadım. Hiçbir şey anlayamadım
    Sonra hepsi kahkahaya boğuldu ve işe alım sürecini başlatmamız gerektiğini söylediler
    Bugün hâlâ stajyerlerle böyle dalga geçiyorlar mı merak ediyorum. O zamanki afallamış hâlimi düşününce hâlâ gülüyorum

  • Ooo! IOCCC geri dönmüş!
    Organizatörlere sevgiler <3 <3 <3 IOCCC'yi sürdürdüğünüz için teşekkürler, umarım bir daha asla kaybolmaz

  • Durun, bunu pek anlayamadım
    Obfuscated C Code Contest olur da Capture the Flag olmaz mı yani? AI yüzünden mi?
    https://twit.tv/posts/tech/ai-disrupts-capture-flag-what-mea...

    • Capture the Flag'in net bir hedefi var ama Obfuscated C Contest'te böyle bir şey yok. Hedef odaklı yarışmalarda AI'ın ilerleme kaydetmesini anlıyorum ama sanatsal sezgi içeren açık uçlu yarışmalarda neyin ilerleme sayılacağını pek bilmiyorum
      Eğer soru "Akıllıca bir fikir bulup sonra AI'dan bunu IOCCC kısıtlarına uygun şekilde uygulamasını istemek mümkün değil mi?" ise, mevcut AI araçlarının bunu henüz insan jüri üyelerinin değerli bulacağı bir düzeyde yapabildiğini sanmıyorum