Introdução
Você provavelmente está familiarizado com bombas zip , bombas XML , etc. Simplificando, eles são arquivos (relativamente) pequenos que produzem resultados enormes quando interpretados por software ingênuo. O desafio aqui é abusar de um compilador da mesma maneira.
Desafio
Escreva um código-fonte que ocupe 512 bytes ou menos e que seja compilado em um arquivo que ocupe o maior espaço possível. Maior arquivo de saída vence!
Regras
OK, existem alguns esclarecimentos, definições e restrições importantes;
- A saída da compilação deve ser um arquivo ELF , um executável portátil do Windows (.exe) ou bytecode virtual para a JVM ou o CLR da .Net (é provável que outros tipos de bytecode virtual também estejam OK se solicitado). Atualização: A saída .pyc / .pyo do Python também conta .
- Se o seu idioma de escolha não puder ser compilado diretamente em um desses formatos, a transpilação seguida da compilação também será permitida ( atualização: você pode transpilar várias vezes, desde que nunca use o mesmo idioma mais de uma vez ).
- Seu código-fonte pode consistir em vários arquivos e até arquivos de recursos, mas o tamanho total de todos esses arquivos não deve exceder 512 bytes.
- Você não pode usar nenhuma outra entrada além do (s) arquivo (s) de origem e a biblioteca padrão do seu idioma de escolha. As bibliotecas padrão de vinculação estática estão OK quando suportadas. Especificamente, nenhuma biblioteca de terceiros ou bibliotecas de SO.
- Deve ser possível chamar sua compilação usando um comando ou uma série de comandos. Se você precisar de sinalizadores específicos ao compilar, estes serão contados no limite de bytes (por exemplo, se sua linha de compilação for
gcc bomb.c -o bomb -O3 -lm
, a-O3 -lm
parte (7 bytes) será contada (observe que o espaço inicial inicial não é contado). - Os pré-processadores são permitidos apenas se forem uma opção de compilação padrão para o seu idioma.
- O ambiente é com você, mas no interesse de tornar isso verificável, atenha-se às versões recentes (disponíveis) do compilador e sistemas operacionais (e, obviamente, especifique qual você está usando).
- Ele deve ser compilado sem erros (os avisos são válidos) e travar o compilador não conta para nada.
- O que seu programa realmente faz é irrelevante, embora não possa ser nada malicioso. Nem precisa ser capaz de começar.
Exemplo 1
O programa C
main(){return 1;}
Compilado Apple LLVM version 7.0.2 (clang-700.1.81)
no OS X 10.11 (64 bits):
clang bomb.c -o bomb -pg
Produz um arquivo de 9228 bytes. O tamanho total da fonte é 17 + 3 (para o -pg
) = 20 bytes, o que está facilmente dentro do limite de tamanho.
Exemplo 2
O programa Brainfuck:
++++++[->++++++++++++<]>.----[--<+++>]<-.+++++++..+++.[--->+<]>-----.--
-[-<+++>]<.---[--->++++<]>-.+++.------.--------.-[---<+>]<.[--->+<]>-.
Transpilado com awib para c com:
./awib < bomb.bf > bomb.c
Em seguida, compilado Apple LLVM version 7.0.2 (clang-700.1.81)
no OS X 10.11 (64 bits):
clang bomb.c
Produz um arquivo de 8464 bytes. A entrada total aqui é de 143 bytes (já que @lang_c
é o padrão para o awib, ele não precisou ser adicionado ao arquivo de origem e não há sinalizadores especiais em nenhum dos comandos).
Observe também que, nesse caso, o arquivo bomb.c temporário tem 802 bytes, mas isso não conta para o tamanho da fonte nem do tamanho da saída.
Nota final
Se uma saída de mais de 4 GB for alcançada (talvez se alguém encontrar um pré-processador completo), a competição será pela menor fonte que produzir um arquivo com pelo menos esse tamanho (não é prático testar envios muito grandes) .