Introducción

Probablemente esté familiarizado con las bombas zip , las bombas XML , etc. En pocas palabras, son archivos (relativamente) pequeños que producen un enorme rendimiento cuando son interpretados por software ingenuo. El desafío aquí es abusar de un compilador de la misma manera.

Desafío

Escriba un código fuente que ocupa 512 bytes o menos y que se compila en un archivo que ocupa el mayor espacio posible. ¡El archivo de salida más grande gana!

Reglas

OK, entonces hay algunas aclaraciones importantes, definiciones y restricciones;

• La salida de la compilación debe ser un archivo ELF , un ejecutable portátil de Windows (.exe) o un código de bytes virtual para JVM o CLR de .Net (es probable que otros tipos de códigos de bytes virtuales también estén bien si se solicitan). Actualización: la salida .pyc / .pyo de Python también cuenta .
• Si su idioma de elección no puede compilarse directamente en uno de esos formatos, también se permite la transpilación seguida de la compilación ( Actualización: puede transpilar varias veces, siempre y cuando nunca use el mismo idioma más de una vez ).
• Su código fuente puede consistir en múltiples archivos, e incluso archivos de recursos, pero el tamaño sumado de todos estos archivos no debe exceder los 512 bytes.
• No puede utilizar ninguna otra entrada que no sea su (s) archivo (s) de origen y la biblioteca estándar de su idioma de elección. La vinculación estática de bibliotecas estándar está bien cuando es compatible. Específicamente, no hay bibliotecas de terceros o bibliotecas del sistema operativo.
• Debe ser posible invocar su compilación utilizando un comando o una serie de comandos. Si necesita indicadores específicos al compilar, estos cuentan para su límite de bytes (por ejemplo, si su línea de compilación es gcc bomb.c -o bomb -O3 -lm, se -O3 -lmcontará la parte (7 bytes) (tenga en cuenta que el espacio inicial no se cuenta).
• Los preprocesadores solo están permitidos si son una opción de compilación estándar para su idioma.
• El entorno depende de usted, pero en aras de hacer que esto sea verificable, respete las versiones de compilador y los sistemas operativos recientes (es decir, disponibles) (y, obviamente, especifique cuál está utilizando).
• Debe compilarse sin errores (las advertencias están bien), y el bloqueo del compilador no cuenta para nada.
• Lo que su programa realmente hace es irrelevante, aunque no puede ser nada malicioso. Ni siquiera tiene que poder comenzar.

Ejemplo 1

El programa C

main(){return 1;}

Compilado con Apple LLVM version 7.0.2 (clang-700.1.81)OS X 10.11 (64 bits):

clang bomb.c -o bomb -pg

Produce un archivo de 9228 bytes. El tamaño total de la fuente es 17 + 3 (para el -pg) = 20 bytes, que está fácilmente dentro del límite de tamaño.

Ejemplo 2

El programa Brainfuck:

++++++[->++++++++++++<]>.----[--<+++>]<-.+++++++..+++.[--->+<]>-----.--
-[-<+++>]<.---[--->++++<]>-.+++.------.--------.-[---<+>]<.[--->+<]>-.

Transpilado con awib a c con:

./awib < bomb.bf > bomb.c

Luego compilado con Apple LLVM version 7.0.2 (clang-700.1.81)OS X 10.11 (64 bits):

clang bomb.c

Produce un archivo de 8464 bytes. La entrada total aquí es de 143 bytes (dado que @lang_ces el valor predeterminado para awib, no era necesario agregarlo al archivo de origen, y no hay indicadores especiales en ninguno de los comandos).

También tenga en cuenta que, en este caso, el archivo temporal bomb.c tiene 802 bytes, pero esto no tiene en cuenta ni el tamaño de origen ni el tamaño de salida.

Nota final

Si se logra una salida de más de 4 GB (tal vez si alguien encuentra un preprocesador completo), la competencia será por la fuente más pequeña que produzca un archivo de al menos ese tamaño (simplemente no es práctico probar envíos que son demasiado grandes) .

C, (14 + 15) = fuente de 29 bytes, ejecutable 17.179.875.837 (16 GB)

Gracias a @viraptor por 6 bytes de descuento.

Gracias a @hvd por 2 bytes de descuento y tamaño ejecutable x4.

Esto define la mainfunción como una gran matriz e inicializa su primer elemento. Esto hace que GCC almacene toda la matriz en el ejecutable resultante.

Debido a que esta matriz es más grande que 2GB, debemos proporcionar el -mcmodel=mediumindicador a GCC. Los 15 bytes adicionales se incluyen en la puntuación, según las reglas.

main[-1u]={1};

No esperes que este código haga algo bueno cuando se ejecute.

Compilar con:

gcc -mcmodel=medium cbomb.c -o cbomb

Me llevó un tiempo probar las sugerencias de @ hvd y encontrar una máquina con suficiente jugo para manejarla. Finalmente encontré una máquina virtual RedHat 5.6 que no es de producción, con 10 GB de RAM, 12 GB de intercambio y / tmp configurados en una gran partición local. La versión de GCC es 4.1.2. Tiempo total de compilación de unos 27 minutos.

Debido a la carga de CPU y RAM, recomiendo no realizar esta compilación en ninguna máquina remota relacionada con la producción .

C #, aproximadamente 1 minuto para compilar, binario de salida de 28 MB:

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;}}

Agregar más Y aumentará el tamaño exponencialmente.

Una explicación de Pharap según la solicitud de @Odomontois:

Esta respuesta es abusar de los parámetros de herencia y tipo para crear recursividad. Para comprender lo que está sucediendo, primero es más fácil simplificar el problema. Considere class X<A> { class Y : X<Y> { Y y; } }, que genera la clase genérica X<A>, que tiene una clase interna Y. X<A>.Yhereda X<Y>, por lo tanto, X<A>.Ytambién tiene una clase interna Y, que es entonces X<A>.Y.Y. Esto también tiene una clase interna Y, y esa clase interna Ytiene una clase interna, Yetc. Esto significa que puede usar la resolución de alcance ( .) hasta el infinito, y cada vez que la usa, el compilador tiene que deducir otro nivel de herencia y parametrización de tipo .

Al agregar parámetros de tipo adicionales, el trabajo que el compilador tiene que hacer en cada etapa se incrementa aún más.

Considere los siguientes casos:
In class X<A> { class Y : X<Y> { Y y;} }type param Atiene un tipo de X<A>.Y.
En class X<A> { class Y : X<Y> { Y.Y y;} }tipo param Atiene un tipo de X<X<A>.Y>.Y.
En class X<A> { class Y : X<Y> { Y.Y.Y y;} }tipo param Atiene un tipo de X<X<X<A>.Y>.Y>.Y.
En class X<A,B> { class Y : X<Y,Y> { Y y;} }tipo param Aes X<A,B>.Yy Bes X<A,B>.Y.
En class X<A> { class Y : X<Y> { Y.Y y;} }tipo param Aes X<X<A,B>.Y, X<A,B>.Y>.Yy Bes X<X<A,B>.Y, X<A,B>.Y>.Y.
En class X<A> { class Y : X<Y> { Y.Y.Y y;} }tipo param Aes X<X<X<A,B>.Y, X<A,B>.Y>.Y, X<X<A,B>.Y, X<A,B>.Y>.Y>.Yy Bes X<X<X<A,B>.Y, X<A,B>.Y>.Y, X<X<A,B>.Y, X<A,B>.Y>.Y>.Y.

Siguiendo este patrón, uno sólo puede imaginar ¹ el trabajo del compilador tendría que hacer para deducir lo Aque Eson en Y.Y.Y.Y.Y.Y.Y.Y.Yla definición 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;}}.

¹ Podrías resolverlo, pero necesitarías mucha paciencia, e intellisense no te ayudará aquí.

Python 3, fuente de 13 bytes, 9.057.900.463 byte (8.5GiB) .pyc-file

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

Editar : Cambié el código a la versión anterior después de que me di cuenta de que las reglas dicen que el tamaño de salida más allá de 4GiB no importa, y el código para este es un poco más corto; El código anterior, y lo que es más importante, la explicación, se puede encontrar a continuación.

Python 3, fuente de 16 bytes, archivo .pyc de 32 TB (si tiene suficiente memoria, espacio en disco y paciencia)

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

Explicación: Python 3 hace un plegado constante, y obtienes grandes números rápidamente con exponenciación. Sin embargo, el formato utilizado por los archivos .pyc almacena la longitud de la representación entera usando 4 bytes, y en realidad el límite parece ser más similar 2**31, por lo que usando solo la exponenciación para generar un gran número, el límite parece generar 2GB. archivo pyc de una fuente de 8 bytes. ( 19**8es un poco tímido 8*2**31, por lo que 1<<19**8tiene una representación binaria de menos de 2 GB; la multiplicación por ocho es porque queremos bytes, no bits)

Sin embargo, las tuplas también son inmutables y la multiplicación de una tupla también se dobla constantemente, por lo que podemos duplicar ese blob de 2GB tantas veces como queramos, hasta al menos 2**31veces, probablemente. La 4**7opción para llegar a 32 TB se eligió solo porque fue el primer exponente que pude encontrar que superó la respuesta anterior de 16 TB.

Desafortunadamente, con la memoria que tengo en mi propia computadora, pude probar esto solo hasta un multiplicador de 2, es decir. (1<<19**8,)*2, que generó un archivo de 8,5 GB, que espero demuestre que la respuesta es realista (es decir, el tamaño del archivo no se limita a 2 ** 32 = 4 GB).

Además, no tengo idea de por qué el tamaño del archivo que obtuve cuando probé fue de 8,5 GB en lugar de los 4 GB que esperaba, y el archivo es lo suficientemente grande como para no tener ganas de hurgarlo en este momento.

Si se logra una salida de más de 4 GB (tal vez si alguien encuentra un preprocesador completo), la competencia será por la fuente más pequeña que produzca un archivo de al menos ese tamaño (simplemente no es práctico probar envíos que son demasiado grandes) .

"Template Haskell" permite que el código de Haskell se genere en tiempo de compilación usando Haskell, y por lo tanto es un preprocesador completo.

Aquí está mi intento, parametrizado por una expresión numérica arbitraria FOO:

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

La magia es el código dentro del "empalme" $(...). Esto se ejecutará en tiempo de compilación, para generar un AST de Haskell, que se injerta en el AST del programa en lugar del empalme.

En este caso, hacemos un AST simple que representa el literal 0, lo repetimos FOOpara hacer una lista, luego usamos ListEdesde el Language.Haskell.THmódulo para convertir esta lista de AST en un gran AST, que representa el literal [0, 0, 0, 0, 0, ...].

El programa resultante es equivalente a main = print [0, 0, 0, ...]con FOOrepeticiones de 0.

Para compilar a 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

Esto pesa 83 bytes (66 para el código Haskell y 17 para el -XTemplateHaskellargumento), más la longitud de FOO.

Podemos evitar el argumento del compilador y simplemente compilar con él ghc, pero tenemos que ponerlo {-# LANGUAGE TemplateHaskell#-}al principio, lo que aumenta el código hasta 97 bytes.

Aquí hay algunas expresiones de ejemplo para FOO, y el tamaño del binario 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

Me quedé sin RAM compilando con (2^20).

También podemos hacer una lista infinita, usando en repeatlugar de replicate FOO, pero eso evita que el compilador se detenga;)

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;

Esta es la función de Ackermann implementada en plantillas. No puedo compilar h=a<4,2>::n;en mi pequeña máquina (6GB), pero logré h=a<3,14>un archivo de salida de 26M. Puede ajustar las constantes para alcanzar los límites de su plataforma; consulte el artículo de Wikipedia vinculado para obtener orientación.

Requiere un -gindicador para GCC (porque son todos los símbolos de depuración los que realmente consumen cualquier espacio) y una profundidad de plantilla mayor que la predeterminada. Mi línea de compilación terminó como

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

Información de la 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 (fuente de 29 bytes, 32 bytes para banderas), 4,294,975,320 bytes ejecutables

.globl main
main:
.zero 1<<32

Compilar con gcc the_file.s -mcmodel=large -Wl,-fuse-ld=gold

Aquí está mi respuesta C de 2005. Produciría un binario de 16 TB si tuviera 16 TB de RAM (no la tiene).

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(){}

Preprocesador C simple: entrada de 214 bytes, salida de 5 MB

Inspirado por mi preprocesador del mundo real, falla aquí .

#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; }

Los experimentos muestran que cada nivel de #defines hará (como se esperaba) que la salida sea aproximadamente diez veces mayor. Pero como este ejemplo tardó más de una hora en compilarse, nunca pasé a "G".

Java, 450 + 22 = fuente de 472 bytes, archivo de clase ~ 1GB

B.java (versión de golf, advertencia durante la compilación)

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 (versión sin golf)

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;
    }
}

Compilacion

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

Explicación

Esta bomba utiliza procesadores de anotación. Necesita 2 pases de compilación. El primer paso construye la clase de procesador B. Durante la segunda pasada, el procesador crea un nuevo archivo fuente C.javay lo compila a C.classun tamaño de1,073,141,162 bytes.

Existen varias limitaciones al intentar crear un archivo de clase grande:

• Crear identificadores de más de 64k resulta en: error: UTF8 representation for string "iiiiiiiiiiiiiiiiiiii..." is too long for the constant pool .
• Crear más de aproximadamente 64k variables / funciones resulta en: error: too many constants
• También hay un límite de aproximadamente 64k para el tamaño del código de una función.
• Parece que hay un límite general (¿error?) En el compilador de Java de aproximadamente 1 GB para el .classarchivo. Si aumento 16380a16390 en el código anterior el compilador nunca regresa.
• También hay un límite de aproximadamente 1 GB para el .javaarchivo. El aumento 16380de 16400en el código anterior da como resultado: An exception has occurred in the compiler (1.8.0_66). Please file a bug ...seguido de a java.lang.IllegalArgumentException.

C, fuente de 26 bytes, salida de 2,139,103,367 bytes, programa válido

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

Compilado usando: gcc cbomb.c -o cbomb(gcc versión 4.6.3, Ubuntu 12.04, ~ 77 segundos)

Pensé que trataría de ver qué tan grande podría hacer un programa válido sin usar ninguna opción de línea de comando. Tengo la idea de esta respuesta: https://codegolf.stackexchange.com/a/69193/44946 de Digital Trauma. Vea los comentarios allí sobre por qué esto se compila.

Cómo funciona: constelimina el indicador de escritura de las páginas del segmento, por lo que se puede ejecutar main. El 195es el código de máquina de Intel para una devolución. Y como la arquitectura Intel es little endian, este es el primer byte. El programa saldrá con el código de inicio que se haya puesto en el registro eax, probablemente 0.

Solo se trata de 2 conciertos porque el enlazador está utilizando valores firmados de 32 bits para las compensaciones. Es 8 meg más pequeño que 2 conciertos porque el compilador / enlazador necesita algo de espacio para trabajar y este es el más grande que podría obtener sin errores del enlazador - ymmv.

Boo , 71 bytes. Tiempo de compilación: 9 minutos. 134,222,236 byte ejecutable

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

Utiliza una macro R(para Repetir) para hacer que el compilador multiplique la declaración de incremento un número arbitrario de veces. No se necesitan indicadores especiales del compilador; simplemente guarde el archivo como bomb.booe invoque el compilador booc bomb.boopara compilarlo.

Kotlin , fuente de 90 bytes, binario JVM compilado de 177416 bytes (173 KB)

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

Técnicamente, podría hacer esto aún más largo al anidar aún más la expresión. Sin embargo, el compilador se bloquea con un StackOverflowerror si aumenta la recursividad.

C ++, 214 bytes (no se necesitan opciones especiales de compilación)

#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();

Es una recursión de plantilla bidimensional bastante sencilla (la profundidad de recursión es la raíz cuadrada del total de plantillas emitidas, por lo que no excederá los límites de la plataforma), con una pequeña cantidad de datos estáticos en cada una.

El archivo de objeto generado con g++ 4.9.3 x86_64-pc-cygwines 2567355421 bytes (2.4GiB).

El aumento del valor inicial por encima de 80 rompe el ensamblador cygwin gcc (demasiados segmentos).

Además, 99999puede ser reemplazado 9<<19o similar para aumentar el tamaño sin cambiar el código fuente ... pero no creo que necesite usar más espacio en disco del que ya tengo;)

Scala: fuente de 70 bytes, resultado de 22980842 bytes (después de jar)

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

Esto produce 9 ⁵ (aproximadamente 59,000) archivos de clase especializados, que se empaquetan en un frasco de aproximadamente 23 MB. En principio, puede continuar si tiene un sistema de archivos que pueda manejar tantos archivos y suficiente memoria.

(Si se debe incluir el comando jar, son 82 bytes).

C, 284 bytes + 2 para la -cen gcc bomb.c -o bomb.o -c; salida: 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, mucho más de lo que puedes esperar de esto

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 tetración