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 -lmparte (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) .

C, (14 + 15) = fonte de 29 bytes, executável de 17.179.875.837 (16 GB) bytes

Graças a @viraptor por 6 bytes de desconto.

Graças a @hvd por 2 bytes de desconto e tamanho executável x4.

Isso define a mainfunção como uma matriz grande e inicializa seu primeiro elemento. Isso faz com que o GCC armazene toda a matriz no executável resultante.

Como esse array é maior que 2 GB, precisamos fornecer o -mcmodel=mediumsinalizador para o GCC. Os 15 bytes extras estão incluídos na pontuação, de acordo com as regras.

main[-1u]={1};

Não espere que esse código faça algo de bom quando executado.

Ajuntar com:

gcc -mcmodel=medium cbomb.c -o cbomb

Levei um tempo para testar a sugestão da @ hvd - e encontrar uma máquina com suco suficiente para lidar com isso. Eventualmente, encontrei uma VM RedHat 5.6 antiga que não era de produção, com 10 GB de RAM, troca de 12 GB e / tmp definida para uma grande partição local. A versão do GCC é 4.1.2. Tempo total de compilação cerca de 27 minutos.

Devido à carga da CPU e da RAM, eu recomendo não fazer essa compilação em qualquer máquina remotamente relacionada à produção .

C #, aproximadamente 1 min para compilar, saída de 28 MB binária:

class X<A,B,C,D,E>{class Y:X<Y,Y,Y,Y,Y>{Y.Y.Y.Y.Y.Y.Y.Y.Y y;}}

A adição de mais Y's aumentará exponencialmente o tamanho.

Uma explicação de Pharap, conforme solicitação do @Odomontois ':

Esta resposta está abusando dos parâmetros de herança e tipo para criar recursão. Para entender o que está acontecendo, é mais fácil simplificar o problema. Considere class X<A> { class Y : X<Y> { Y y; } }, o que gera a classe genérica X<A>, que possui uma classe interna Y. X<A>.Yherda X<Y>, portanto, X<A>.Ytambém tem uma classe interna Y, que é então X<A>.Y.Y. Isso também tem uma classe interna Y, e essa classe interna Ytem uma classe interna Yetc. Isso significa que você pode usar a resolução do escopo ( .) ad infinitum e toda vez que usá-la, o compilador deve deduzir outro nível de herança e parametrização de tipo .

Ao adicionar parâmetros de tipo adicionais, o trabalho que o compilador deve realizar em cada estágio é aumentado.

Considere os seguintes casos:
No class X<A> { class Y : X<Y> { Y y;} }tipo, param Atem um tipo de X<A>.Y.
No class X<A> { class Y : X<Y> { Y.Y y;} }tipo, param Atem um tipo de X<X<A>.Y>.Y.
No class X<A> { class Y : X<Y> { Y.Y.Y y;} }tipo, param Atem um tipo de X<X<X<A>.Y>.Y>.Y.
No class X<A,B> { class Y : X<Y,Y> { Y y;} }tipo param Aé X<A,B>.Ye Bé X<A,B>.Y.
No class X<A> { class Y : X<Y> { Y.Y y;} }tipo param Aé X<X<A,B>.Y, X<A,B>.Y>.Ye Bé X<X<A,B>.Y, X<A,B>.Y>.Y.
No class X<A> { class Y : X<Y> { Y.Y.Y y;} }tipo param Aé X<X<X<A,B>.Y, X<A,B>.Y>.Y, X<X<A,B>.Y, X<A,B>.Y>.Y>.Ye Bé X<X<X<A,B>.Y, X<A,B>.Y>.Y, X<X<A,B>.Y, X<A,B>.Y>.Y>.Y.

Seguindo esse padrão, só podemos imaginar ¹ o trabalho que o compilador teria que fazer para deduzir o Aque Eestá na Y.Y.Y.Y.Y.Y.Y.Y.Ydefinição class X<A,B,C,D,E>{class Y:X<Y,Y,Y,Y,Y>{Y.Y.Y.Y.Y.Y.Y.Y.Y y;}}.

¹ Você pode descobrir isso, mas precisa de muita paciência, e o senso comum não o ajudará aqui.

Fonte Python 3, 13 bytes, 9.057.900.463 bytes (8,5GiB) .pyc-file

(1<<19**8,)*2

Editar : Alterei o código para a versão acima depois que percebi que as regras dizem que o tamanho da saída além do 4GiB não importa, e o código para este é cada vez mais curto; O código anterior - e mais importante a explicação - pode ser encontrado abaixo.

Fonte Python 3, 16 bytes,> 32TB .pyc-file (se você tiver memória suficiente, espaço em disco e paciência)

(1<<19**8,)*4**7

Explicação: O Python 3 faz dobragem constante e você obtém grandes números rapidamente com a exponenciação. No entanto, o formato usado pelos arquivos .pyc armazena o comprimento da representação inteira usando 4 bytes e, na realidade, o limite parece ser mais semelhante 2**31; portanto, usando apenas a exponentação para gerar um número grande, o limite parece estar gerando 2 GB. arquivo pyc de uma fonte de 8 bytes. ( 19**8é um pouco tímido 8*2**31, por isso 1<<19**8tem uma representação binária de menos de 2 GB; a multiplicação por oito é porque queremos bytes, não bits)

No entanto, as tuplas também são imutáveis ​​e a multiplicação de uma tupla também é dobrada constantemente, para que possamos duplicar esse blob de 2 GB quantas vezes quisermos, até pelo menos 2**31vezes, provavelmente. O número 4**7de 32 TB foi escolhido apenas porque foi o primeiro expoente que pude encontrar que superou a resposta anterior de 16 TB.

Infelizmente, com a memória que tenho no meu computador, eu poderia testar isso apenas até um multiplicador de 2, ou seja. (1<<19**8,)*2, que gerou um arquivo de 8,5 GB, que espero demonstre que a resposta é realista (ou seja, o tamanho do arquivo não está limitado a 2 ** 32 = 4 GB).

Além disso, não tenho idéia de por que o tamanho do arquivo que obtive durante os testes foi de 8,5 GB em vez dos 4 GB que eu esperava, e o arquivo é grande o suficiente para que eu não sinta vontade de procurá-lo no momento.

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) .

"Template Haskell" permite que o código Haskell seja gerado em tempo de compilação usando Haskell e, portanto, é um pré-processador completo.

Aqui está minha tentativa, parametrizada por uma expressão numérica arbitrária FOO:

import Language.Haskell.TH;main=print $(ListE .replicate FOO<$>[|0|])

A mágica é o código dentro da "emenda" $(...). Isso será executado em tempo de compilação, para gerar um Haskell AST, que é enxertado no AST do programa no lugar da emenda.

Nesse caso, criamos um AST simples representando o literal 0, replicamos esse FOOtempo para fazer uma lista e usamos ListEo Language.Haskell.THmódulo para transformar essa lista de ASTs em um grande AST, representando o literal [0, 0, 0, 0, 0, ...].

O programa resultante é equivalente a main = print [0, 0, 0, ...]com FOOrepetições de 0.

Para compilar no ELF:

$ ghc -XTemplateHaskell big.hs
[1 of 1] Compiling Main             ( big.hs, big.o )
Linking big ...
$ file big
big: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /nix/store/mibabdfiaznqaxqiy4bqhj3m9gaj45km-glibc-2.21/lib/ld-linux.so.2, for GNU/Linux 2.6.32, not stripped

Isso pesa 83 bytes (66 para o código Haskell e 17 para o -XTemplateHaskellargumento), mais o comprimento de FOO.

Podemos evitar o argumento do compilador e apenas compilar ghc, mas temos que colocar {-# LANGUAGE TemplateHaskell#-}no início, que aumenta o código em até 97 bytes.

Aqui estão alguns exemplos de expressões para FOOe o tamanho do binário resultante:

FOO         FOO size    Total size    Binary size
-------------------------------------------------
(2^10)      6B          89B           1.1MB
(2^15)      6B          89B           3.6MB
(2^17)      6B          89B           12MB
(2^18)      6B          89B           23MB
(2^19)      6B          89B           44MB

Fiquei sem memória RAM ao compilar (2^20).

Também podemos fazer uma lista infinita, usando em repeatvez de replicate FOO, mas isso impede que o compilador pare;)

C ++, 250 + 26 = 276 bytes

template<int A,int B>struct a{static const int n;};
template<int A,int B>const int a<A,B>::n=a<A-1,a<A,B-1>::n>::n;
template<int A>struct a<A,0>{static const int n=a<A-1,1>::n;};
template<int B>struct a<0,B>{static const int n=B+1;};
int h=a<4,2>::n;

Essa é a função Ackermann implementada em modelos. Não consigo compilar h=a<4,2>::n;na minha pequena máquina (6 GB), mas consegui h=a<3,14>obter um arquivo de saída de 26 milhões. Você pode ajustar as constantes para atingir os limites da sua plataforma - consulte o artigo vinculado da Wikipedia para obter orientação.

Requer -gsinalizador para o GCC (porque são todos os símbolos de depuração que realmente consomem espaço) e uma profundidade de modelo maior que o padrão. Minha linha de compilação acabou como

g++ -ftemplate-depth=999999 -g -c -o 69189.o 69189.cpp

Informações da plataforma

g++ (Ubuntu 4.8.2-19ubuntu1) 4.8.2
Linux 3.13.0-46-generic #79-Ubuntu SMP x86_64 GNU/Linux

ASM, 61 bytes (fonte de 29 bytes, 32 bytes para sinalizadores), 4.294.975.320 bytes executáveis

.globl main
main:
.zero 1<<32

Ajuntar com gcc the_file.s -mcmodel=large -Wl,-fuse-ld=gold

Aqui está a minha resposta C de 2005. Produziria um binário de 16 TB se você tivesse 16 TB de RAM (você não).

struct indblock{
   uint32_t blocks[4096];
};

struct dindblock {
    struct indblock blocks[4096];
};

struct tindblock {
    struct dindblock blocks[4096];
};

struct inode {
    char data[52]; /* not bothering to retype the details */
    struct indblock ind;
    struct dindblock dint;
    struct tindblock tind;
};

struct inode bbtinode;

int main(){}

Pré-processador C simples antigo: entrada de 214 bytes, saída de 5 MB

Inspirado pelo meu pré-processador do mundo real falhar aqui .

#define A B+B+B+B+B+B+B+B+B+B
#define B C+C+C+C+C+C+C+C+C+C
#define C D+D+D+D+D+D+D+D+D+D
#define D E+E+E+E+E+E+E+E+E+E
#define E F+F+F+F+F+F+F+F+F+F
#define F x+x+x+x+x+x+x+x+x+x

int main(void) { int x, y = A; }

As experiências mostram que cada nível de #defines aumentará (como esperado) a produção aproximadamente dez vezes maior. Mas como esse exemplo levou mais de uma hora para compilar, nunca fui para "G".

Java, 450 + 22 = origem de 472 bytes, arquivo de classe ~ 1 GB

B.java (versão para golfe, aviso durante a compilação)

import javax.annotation.processing.*;@SupportedAnnotationTypes("java.lang.Override")public class B extends AbstractProcessor{@Override public boolean process(java.util.Set a,RoundEnvironment r){if(a.size()>0){try(java.io.Writer w=processingEnv.getFiler().createSourceFile("C").openWriter()){w.write("class C{int ");for(int i=0;i<16380;++i){for(int j=0;j<65500;++j){w.write("i");}w.write(i+";int ");}w.write("i;}");}catch(Exception e){}}return true;}}

B.java (versão não destruída)

import java.io.Writer;
import java.util.Set;

import javax.annotation.processing.AbstractProcessor;
import javax.annotation.processing.RoundEnvironment;
import javax.annotation.processing.SupportedAnnotationTypes;
import javax.annotation.processing.SupportedSourceVersion;
import javax.lang.model.SourceVersion;
import javax.lang.model.element.TypeElement;

@SupportedAnnotationTypes("java.lang.Override")
@SupportedSourceVersion(SourceVersion.RELEASE_8)
public class B extends AbstractProcessor {
    @Override
    public boolean process(Set<? extends TypeElement> annotations, RoundEnvironment roundEnv) {
        if (annotations.size() > 0) {
            try (Writer writer = processingEnv.getFiler().createSourceFile("C").openWriter()) {
                writer.write("class C{int ");
                for (int i = 0; i < 16380; ++i) {
                    for (int j = 0; j < 65500; ++j) {
                        writer.write("i");
                    }
                    writer.write(i + ";int ");
                }
                writer.write("i;}");
            } catch (Exception e) {
            }
        }
        return true;
    }
}

Compilação

javac B.java
javac -J-Xmx16G -processor B B.java

Explicação

Esta bomba usa processadores de anotação. Ele precisa de 2 passes de compilação. A primeira passagem cria a classe do processador B. Durante a segunda passagem, o processador cria um novo arquivo de origem C.javae o compila em C.classum tamanho de 1,073,141,162bytes.

Existem várias limitações ao tentar criar um arquivo de classe grande:

• Criando identificadores de mais de cerca de 64k resulta em: error: UTF8 representation for string "iiiiiiiiiiiiiiiiiiii..." is too long for the constant pool.
• A criação de mais de 64k variáveis ​​/ funções resulta em: error: too many constants
• Há também um limite de cerca de 64k para o tamanho do código de uma função.
• Parece haver um limite geral (bug?) No compilador java de cerca de 1 GB para o .classarquivo. Se eu aumentar 16380para 16390o código acima, o compilador nunca retornará.
• Há também um limite de cerca de 1 GB para o .javaarquivo. Aumentar 16380para 16400o código acima resulta em: An exception has occurred in the compiler (1.8.0_66). Please file a bug ...seguido de a java.lang.IllegalArgumentException.

C, fonte de 26 bytes, saída de 2.139.103.367 bytes, programa válido

const main[255<<21]={195};

Compilado usando: gcc cbomb.c -o cbomb(gcc versão 4.6.3, Ubuntu 12.04, ~ 77 segundos)

Eu pensei em tentar ver o quão grande eu poderia criar um programa válido sem usar nenhuma opção de linha de comando. Eu obtive a ideia desta resposta: https://codegolf.stackexchange.com/a/69193/44946 da Digital Trauma. Veja os comentários sobre por que isso é compilado.

Como funciona: O constremove o sinalizador de gravação das páginas do segmento, para que o main possa ser executado. O 195é o código da máquina Intel para retorno. E como a arquitetura Intel é pouco endian, esse é o primeiro byte. O programa será encerrado com qualquer código de inicialização inserido no registro eax, provavelmente 0.

É apenas cerca de 2 GB, porque o vinculador está usando valores assinados de 32 bits para compensações. É 8 meg menor que 2 gig porque o compilador / vinculador precisa de algum espaço para funcionar e este é o maior que eu poderia obtê-lo sem erros no vinculador - ymmv.

Boo , 71 bytes. Tempo de compilação: 9 minutos. Executável de 134.222.236 bytes

macro R(e as int):
 for i in range(2**e):yield R.Body
x = 0
R 25:++x

Usa uma macro R(para Repetir) para fazer com que o compilador multiplique a instrução de incremento um número arbitrário de vezes. Nenhum sinalizador especial do compilador é necessário; simplesmente salve o arquivo como bomb.booe chame o compilador booc bomb.boopara construí-lo.

Kotlin , origem de 90 bytes, 177416 bytes (173 KB) binário da JVM compilado

inline fun a(x:(Int)->Any){x(0);x(1)}
fun b()=a{a{a{a{a{a{a{a{a{a{a{println(it)}}}}}}}}}}}

Tecnicamente, você pode tornar isso ainda mais longo, aninhando ainda mais a expressão. No entanto, o compilador falha com um StackOverflowerro se você aumentar a recursão.

C ++, 214 bytes (não são necessárias opções especiais de compilação)

#define Z struct X
#define T template<int N
T,int M=N>Z;struct Y{static int f(){return 0;}};T>Z<N,0>:Y{};T>Z<0,N>:Y{};T,int M>Z{static int f(){static int x[99999]={X<N-1,M>::f()+X<N,M-1>::f()};}};int x=X<80>::f();

É uma recursão de modelo bidimensional bastante direta (a profundidade da recursão é a raiz quadrada do total de modelos emitidos, portanto não excede os limites da plataforma), com uma pequena quantidade de dados estáticos em cada um.

O arquivo de objeto gerado g++ 4.9.3 x86_64-pc-cygwiné de 2567355421 bytes (2,4GiB).

Aumentar o valor inicial acima de 80 interrompe o assembler do cygwin gcc (muitos segmentos).

Além disso, 99999pode ser substituído por 9<<19ou similar para aumentar o tamanho sem alterar o código-fonte ... mas acho que não preciso usar mais espaço em disco do que já sou;)

Scala - fonte de 70 bytes, resultado de 22980842 bytes (após o jar)

import scala.{specialized => s}
class X[@s A, @s B, @s C, @s D, @s E]

Isso produz 9 ⁵ (cerca de 59.000) arquivos de classe especializados, que são compactados em um pote de cerca de 23 MB. Em princípio, você pode continuar se tiver um sistema de arquivos capaz de lidar com tantos arquivos e memória suficiente.

(Se o comando jar precisar ser incluído, são 82 bytes.)

C, 284 bytes + 2 para o -cna gcc bomb.c -o bomb.o -c; saída: 2 147 484 052 bytes

#define a 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1
#define b a,a,a,a,a,a,a,a,a,a,a,a,a,a,a,a
#define c b,b,b,b,b,b,b,b,b,b,b,b,b,b,b,b
#define d c,c,c,c,c,c,c,c,c,c,c,c,c,c,c,c
#define e d,d,d,d,d,d,d,d,d,d,d,d,d,d,d,d
#define f e,e,e,e,e,e,e,e,e,e,e,e,e,e,e,e
__int128 x[]={f,f,f,f,f,f,f,f};

Boo, muito mais do que você pode esperar disso

macro R(e as int):for i in range(9**e):yield R.Body
x = 0
R 99:++x

Python 3:

9**9**9**9**9

Bomba de tetração