Anunciados os vencedores da 29ª edição do IOCCC 2025

 (ioccc.org)
3 pontos por GN⁺ 8 시간 전 | 1 comentários | Compartilhar no WhatsApp
  • O International Obfuscated C Code Contest (Concurso Internacional de Código C Ofuscado) é uma competição de programação em computador dedicada ao código C 'ofuscado' mais criativo, artístico e difícil de ler
  • Foi a segunda edição consecutiva realizada após o hiato de 2020 a 2024, e o número de inscrições ficou parecido com o do ano anterior, enquanto a escala e a qualidade dos trabalhos enviados se mantiveram em nível histórico
  • Yusuke Endoh, Nick Craig-Wood e Don Yang conquistaram um hat-trick, com 3 trabalhos premiados cada, e houve um novo vencedor de Taiwan
  • Foram escolhidos vencedores variados, incluindo um computador Subleq, um emulador de GameBoy e um quine de patch/diff, com a introdução de um Fun challenge para cada trabalho premiado
  • O anúncio dos vencedores foi feito em um programa ao vivo no canal do YouTube Our Favorite Universe, e o próximo IOCCC30 está previsto para o fim de 2026

Ponto de partida

  • Os links para as entradas vencedoras do IOCCC de 2025 podem ser encontrados na lista de premiados ao final da página
  • O index.html de cada entrada vencedora fornece a maior parte das informações necessárias para compilar e executar o programa premiado
  • É possível ler o código-fonte vencedor para entender como ele funciona, e ver detalhes adicionais na explicação do autor
  • Todos os vencedores deste ano podem ser baixados em um tarball compactado

Observações gerais sobre este concurso

  • O volume e a qualidade das submissões do IOCCC29 ficaram próximos de máximas históricas
  • O IOCCC28 foi alvo da hipótese de que, após um hiato de 4 anos, os participantes tiveram tempo para lapidar suas submissões, o que teria levado a um número recorde de envios e a uma qualidade acima do normal
  • O IOCCC29 foi a segunda edição consecutiva após o hiato de 2020 a 2024, mas teve quantidade de submissões semelhante à do ano anterior e manteve um alto nível geral de qualidade
  • Desde o encerramento do IOCCC28, foram cuidadosamente documentados o fechamento para novas submissões, o processo de julgamento, a seleção dos vencedores, a atualização do site e a produção do programa ao vivo do Our Favorite Universe
  • A documentação exigiu tempo e esforço extras, mas como resultado houve melhorias em toda a forma de operação do IOCCC
  • Alguns dias após o anúncio dos vencedores do IOCCC29 no canal do YouTube Our Favorite Universe, a gravação principal do programa será dividida em segmentos individuais
  • Perto do topo do index.html de cada entrada vencedora, será adicionada uma nova seção Award presentation com links para os segmentos no YouTube

  • Informações sobre os desafios divertidos

    • Neste ano, foi adicionado um desafio divertido abaixo da seção “Judges’ remarks” dos trabalhos premiados
    • Recomenda-se tentar o desafio depois de entender o funcionamento do trabalho premiado em questão
    • Alguns desafios são mais fáceis do que outros e, em certos casos, exigem criar uma versão alternativa de prog.c ou de arquivos relacionados
    • Alguns desafios pedem a elaboração de uma explicação para um item específico
    • Se a seção “A fun challenge” de um trabalho premiado específico ainda estiver marcada como still open, é possível contribuir enviando um GitHub pull request
    • Mesmo que o desafio já esteja fechado, ainda é possível enviar um GitHub pull request se você acreditar ter uma solução melhor
    • Se os juízes do IOCCC concordarem que se trata de uma solução melhor, ela será considerada
    • Se houver uma melhoria melhor para um desafio divertido de um trabalho premiado, é possível enviar um GitHub pull request para análise dos juízes do IOCCC

  • Regras e diretrizes deste concurso

    • As regras finais aplicadas a esta edição foram a versão 29.15 2025-12-02 de 2025 rules
    • As diretrizes finais aplicadas a esta edição foram a versão 29.08 2025-12-02 de 2025 guidelines
    • As regras e diretrizes do IOCCC29 passaram por uma grande reformulação em relação à edição anterior
    • Vários voluntários forneceram aos juízes do IOCCC edições úteis, revisões de texto, consolidação e melhorias gerais de estrutura

  • Rumo ao próximo concurso

    • A abertura do IOCCC30 está planejada para o fim de 2026
    • O IOCCC30 terá duração semelhante e está previsto para terminar perto do fim do primeiro trimestre de 2027
    • Ao realizar o trabalho necessário para abrir o IOCCC30, também há planos de documentar os procedimentos internos, assim como foi feito no encerramento do IOCCC29
    • Cerca de 2 a 3 semanas após a publicação dos vencedores do IOCCC29 e depois de processar alguns pull requests iniciais da árvore de diretórios de 2025, os juízes do IOCCC planejam entrar em IOCCC vacation
    • Após a divulgação dos vencedores do IOCCC28, também havia planos para uma IOCCC vacation, mas muito tempo foi consumido corrigindo bugs e implementando melhorias no repositório mkiocccentry, e quando o repositório se estabilizou já havia chegado o momento de abrir o IOCCC29
    • Desta vez, após o fim da IOCCC vacation pós-IOCCC29, está planejado trabalhar nos PRs do repositório mkiocccentry
    Publicidade

Observações sobre alguns trabalhos premiados

  • Durante o processo de redigir possíveis textos sobre as submissões que chegaram à rodada final do conjunto final de rodadas de julgamento, algumas submissões foram eliminadas no estágio derradeiro da rodada final
  • Houve admiração adicional e reavaliação positiva em relação a várias das entradas restantes
  • Os autores premiados vieram tanto de regiões já vistas entre vencedores anteriores quanto de uma nova região no IOCCC29, com jingp49 de Taiwan
  • Três autores venceram com três entradas cada, formando Hat-tricks de Hat trick)
  • Alguns dos trabalhos vencedores mais notáveis do IOCCC29 incluem:
  • A lista acima representa apenas parte dos muitos vencedores excelentes do IOCCC29

  • Observações sobre algumas submissões que não venceram

    • Houve muitas submissões excelentes que chegaram muito perto da seleção final, mas não foram premiadas
    • O esforço colocado por cada autor em sua entrada é muito valorizado, mas os prêmios não podem ser dados com base apenas no esforço
    • Códigos enviados ao IOCCC29 que não venceram podem ser lapidados e reenviados ao IOCCC30
    • Pelo menos um dos vencedores do IOCCC29 é uma versão aprimorada de um código que não havia vencido em um concurso anterior

  • Incentivo para os participantes que não venceram neste ano

    • As submissões deste ano ao IOCCC exigiram muito esforço, mas não é possível premiar todas elas
    • Premiar todas as submissões tiraria o significado das submissões consideradas as melhores e merecedoras do prêmio
    • Uma submissão da rodada final pode ser boa o bastante para ser vencedora, mas ainda assim perder para outra muito parecida e um pouco melhor
    • Quando esse for o caso, recomenda-se enviar uma versão aprimorada na próxima edição do IOCCC
    • Há submissões que chegaram ao nível de vencedoras após passarem por várias rodadas de revisão e reenvio
    • Também é possível tentar um tipo completamente diferente de submissão no próximo IOCCC
    • Se não houver planos de melhorar e reenviar uma entrada não premiada no próximo IOCCC, ela poderá ser tornada pública
    Publicidade

Compilando e executando os vencedores

Vencedores da 29ª edição do IOCCC em 2025

Leituras relacionadas

1 comentários

 
GN⁺ 8 시간 전
Comentários do Hacker News

  • O código do emulador de GameBoy chega até a parecer um GameBoy. É louco a ponto de merecer um aplauso lento, e pessoalmente foi minha obra favorita desta edição
    https://github.com/ioccc-src/winner/blob/master/2025/ncw1/pr...
    O autor, Nick Craig-Wood, é a pessoa que criou o rclone

    • Fico feliz que você tenha gostado :-) Se quiser ver como foi feito, o original está aqui
      https://github.com/ncw/ioccc-gameboy
      Lá também existe mais ou menos uma versão não ofuscada. Na prática, foi nela que trabalhei, e depois usei um programa para achatar todos os nomes de variáveis e comprimir tudo para caber no formato de um GameBoy
      O mais difícil foi o limite de tamanho da inscrição. As submissões do IOCCC permitem até 2503 caracteres sem contar espaços, e o tamanho total do código é 4 KB, o que é realmente minúsculo para enfiar um processador Z80 e um emulador do hardware do GameBoy
      No começo, escrevi um emulador de GameBoy completo em C e parti de cerca de 6000 caracteres sem contar espaços. Depois disso, gastei umas 100 horas tentando encaixar tudo no limite de 2503 caracteres, e por um tempo nem tive certeza de que daria para caber
      Defini como objetivo rodar Tetris. Como Tetris é um jogo relativamente simples, removi recursos desnecessários, como a flag half carry do emulador Z80 e o sistema de windowing da emulação do GameBoy. Também forcei o código C de um jeito horrível e até fiz coisas com implicit int que nunca mais vou esquecer. Como o verificador de regras do IOCCC é implementado como um programa em C, também passei tempo fazendo engenharia reversa nele para encontrar brechas. Foi especialmente útil descobrir que certos operadores contam como apenas um token
      Depois que ficou pequeno o bastante, ainda precisei colocar jogos para executar. Fiz quatro: um programa de teste escrito em assembly Z80, uma calculadora de pi feita em assembly, um jogo da velha 3D em C feito com gbdk-2020 e um programa de xadrez em C. Também descobri que bastante jogo open source roda nesse emulador, então adicionei um downloader quando era possível. Surpreendentemente, não há tantos jogos que usam aritmética BCD
      Foi um projeto divertido
    • https://github.com/ncw/ccforth
      https://github.com/ncw/ccforth/tree/master/examples/gameboy
    • Incrível! E eu aqui mexendo com CSS e PHP ao ver isso
    • Fazer o código parecer uma imagem é um clichê bastante usado em competições de programação ofuscada

  • O que eu mais gostei foi o emulador em C de 366 bytes capaz de rodar Linux e Doom [0]
    Essa máquina virtual implementa um OISC, ou seja, um computador de instrução única [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...

    • Nas últimas semanas, eu estava criando minha linguagem de programação simples que compila para assembly Linux/amd64
      Eu poderia até escrever um monte de rotinas de biblioteca padrão, como abrir arquivos, executar comandos de shell, strstr, strcpy, e sinceramente acabei implementando coisas que não eram necessárias para o aprendizado. Por exemplo, print(getenv("HOME")) funciona. Mas logo percebi que precisava de programas de exemplo para testar e também para mostrar
      Então, naturalmente, o primeiro programa de verdade que implementei foi um interpretador de brainfuck. Graças a isso, minha linguagem agora é indiretamente Turing-completa
      A versão inicial levava 9 minutos para produzir a saída do famoso programa mandelbrot, então fiz várias otimizações e depois também adicionei suporte a instruções switch/case para acelerar. Agora ela consegue gerar a mesma saída em 2 minutos, então ainda há espaço para melhorar, mas já houve bastante progresso
      Foi muito satisfatório implementar outra linguagem dentro da minha própria linguagem de um jeito meio trapaceiro. Claro, tudo isso é por diversão e aprendizado, e não foi feito para ninguém usar a sério, inclusive eu mesmo
      https://github.com/skx/s-lang
    • Uau! E também implementaram uma variante de SUBLEQ Turing-completa de um jeito bem interessante

      Esta VM implementa um OISC, ou One Instruction Set Computer. Essa instrução recebe três operandos de 32 bits com sinal, a, b, c, e executa o programa na memória m[] da seguinte forma:
      1 O PC (program counter) começa em 0
      2 Busca a próxima instrução, ou seja, os operandos de 32 bits com sinal a, b, c
      3 Se qualquer operando tiver o bit menos significativo ativado, esse bit é removido e o operando correspondente é trocado por m[operand], ou seja, o valor dereferenciado naquele endereço
      4 Define m[b] = m[b] - m[a]
      5 Se m[b] for menor ou igual a 0, define o PC como c; caso contrário, incrementa o PC em 3 palavras
      6 Volta ao passo 2

    • Acho que gosto da ideia, mas a Eternal Software Initiative vinculada [1] é um pouco confusa. Há várias versões da descrição da instrução para decodificar isso, e elas entram em conflito entre si
      Aqui diz para definir m[b] = m[b] - m[a]
      Depois isso leva à implementação de referência no GitHub [2], onde diz que basta ter o rascunho no guardanapo [3]. Ele divide por 4 todos os valores lidos, e a implementação de referência [4] também sustenta isso. Mas não está claro por que escolheram 4 em vez de 2. Parece desperdiçar um bit. Fico me perguntando se esse bit era necessário ou se foi reservado para alguma expansão futura
      A implementação original não dividia por 4 e isso parece ter sido adicionado depois, mas não entendo por que isso era necessário, além de talvez facilitar um pouco a geração de código LLVM. Para confirmar se o sistema descrito seria impossível sem dividir por 4, eu provavelmente teria de seguir muitos exemplos passo a passo. Talvez o principal problema fosse que só seria possível acessar endereços pares, e como o PC avança 3 a cada vez, referenciar posições de código certamente seria incômodo
      A implementação de referência faz algo mágico ao acessar a posição 64, sobrescrevendo as posições 64~67 com a hora atual. Isso aparece na descrição do guardanapo, mas não na explicação da página principal
      As duas descrições mencionam o endereço mágico -1, então é estranho que o relógio UTC dependente da implementação não tenha sido implementado com endereços negativos, em vez de corromper memória livremente utilizável
      As duas descrições também mencionam o processo de interrupção de timer periódica, e isso também é uma pena. Os endereços 0 e 1 são reutilizados como a posição do handler de interrupção e o PC salvo, então é preciso sobrescrever a posição 0, que era o ponto de entrada inicial, logo após o início do programa
      [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
    • Baixei e fiz o build, e posso dizer com confiança que é a coisa mais impressionante que já vi até agora
    • O vídeo está aqui
      https://www.youtube.com/live/MoWCwZx1Swc?si=eIOlRsKWNKRVRZeB...

  • Caso alguém esteja curioso: o IOCCC permite explicitamente o uso de LLMs nas diretrizes
    "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."

    • Eu tendo mais para o lado não-IA, mas nesse caso acho interessante. Principalmente porque não há muito código C ofuscado online, e LLMs também têm dificuldade para inferir a intenção a partir de código real. Fico curioso se alguém já viu uma submissão feita com ajuda de LLM
      O contrário também é interessante. Até que ponto um LLM conseguiria adivinhar corretamente a função de um código ofuscado?
    • Isso afeta principalmente os jurados. É como abrir deliberadamente a porta para uma enxurrada de código ruim, mas, pela natureza do concurso, os jurados provavelmente sabem distinguir muito bem código interessante de código de baixa qualidade
      Acho bom que o IOCCC aceite código que talvez tenha sido feito com ajuda de máquinas. Isso faz o valor das obras vencedoras puramente manuais parecer ainda maior
    • Então isso virou um campeonato de ginástica de LLM?
    • Se IA entra na definição de "ferramentas", então a regra 7 se torna autocontraditória
      https://www.ioccc.org/2025/rules.html
      Parece que o que está sendo dito aqui se refere a geradores de código personalizados. O texto fala explicitamente de uma "rica história", e, se essa expressão inclui até a época em que não existia IA, não entendo por que isso deveria ser interpretado como referência a IA

  • O próprio site também é ofuscado, então não é nada fácil encontrar o código-fonte em C

    • É só ir direto para https://www.ioccc.org/2025/#inventory
    • É realmente muito difícil de navegar. Não dá para entender do que se trata o concurso, e parece feito partindo do pressuposto de que você já sabe
    • A primeira frase leva à seção com a lista dos vencedores, e há um link C code no canto superior direito de cada obra vencedora

  • Queria que o Underhanded C Contest voltasse. Não é para menosprezar os participantes do Obfuscated C, mas aquele sempre foi muito mais interessante para mim

  • Tem uma referência a Frieren aqui! [1]
    https://www.ioccc.org/2025/yang2/index.html
    Um dos protagonistas é Fern, e ela usa quase exclusivamente a magia ofensiva comum Zoltraak
    [1] https://en.wikipedia.org/wiki/Frieren

  • Meu Deus, uma implementação minha de Game Boy do Jogo da Vida está em uma das obras vencedoras!

    • Depois de criar o emulador, fui procurar no GitHub jogos que pudessem rodar dentro do limite de 32 KB. Encontrei o seu, obrigado :-) Coloquei uma opção no script ./try.sh para que os usuários possam baixar do GitHub e testar

  • Fiz minha primeira entrevista de estágio em 2000, para entrar numa equipe de programadores C. Os entrevistadores me mostraram uma antiga obra vencedora e saíram da sala, pedindo para eu revisar o código. Uns 5 minutos depois voltaram e perguntaram
    – Então?
    – Desculpem, fiz vocês perderem tempo. Não consigo entender absolutamente nada
    Aí todos começaram a rir e disseram para começarmos o processo de contratação
    Fico me perguntando se ainda pregam peças assim em estagiários hoje em dia. Ainda rio quando lembro do meu desespero naquela hora

  • Oooooh! O IOCCC voltou!
    Muito amor aos organizadores <3 <3 <3 obrigado por manterem o IOCCC vivo, e espero que ele nunca mais desapareça

  • Espera aí, não estou entendendo muito bem
    Então Obfuscated C Code Contest pode, mas Capture the Flag não pode? Por causa de IA?
    https://twit.tv/posts/tech/ai-disrupts-capture-flag-what-mea...

    • Capture the Flag tem um objetivo claro, mas o Obfuscated C Contest não. Eu entendo a ideia de progresso da IA em competições orientadas a objetivos, mas em concursos abertos que envolvem senso artístico, não sei bem o que deveria contar como progresso
      Se a pergunta é "não daria para ter uma ideia inteligente e depois pedir para a IA implementá-la dentro das restrições do IOCCC?", eu diria que as ferramentas de IA atuais ainda não conseguem fazer isso num nível que jurados humanos considerariam valioso