Введение

Вы, вероятно, знакомы с zip-бомбами , XML-бомбами и т. Д. Проще говоря, это (относительно) небольшие файлы, которые дают огромный результат при интерпретации наивным программным обеспечением. Задача здесь заключается в том, чтобы так же злоупотреблять компилятором.

Вызов

Напишите некоторый исходный код, который занимает 512 байт или меньше и который компилируется в файл, который занимает максимально возможное пространство. Самый большой выходной файл выигрывает!

правила

Итак, есть несколько важных уточнений, определений и ограничений;

• Выходными данными компиляции должны быть файл ELF , исполняемый файл Windows (.exe) или виртуальный байт-код для JVM или CLR .Net (другие типы виртуальных байт-кодов также могут быть в порядке, если их попросить). Обновление: вывод Python в .pyc / .pyo также имеет значение .
• Если выбранный вами язык не может быть скомпилирован непосредственно в один из этих форматов, то также разрешена транспиляция с последующей компиляцией ( Обновление: вы можете переносить несколько раз, только если вы никогда не используете один и тот же язык более одного раза ).
• Ваш исходный код может состоять из нескольких файлов и даже файлов ресурсов, но суммарный размер всех этих файлов не должен превышать 512 байт.
• Вы не можете использовать другие входные данные, кроме вашего исходного файла (ов) и стандартной библиотеки вашего языка по вашему выбору. Статическое связывание стандартных библиотек в порядке, если оно поддерживается. В частности, нет сторонних библиотек или библиотек ОС.
• Должна быть возможность вызвать компиляцию с помощью команды или серии команд. Если при компиляции вам требуются определенные флаги, они учитываются в пределах вашего байтового предела (например, если у вас есть строка компиляции gcc bomb.c -o bomb -O3 -lm, -O3 -lmбудет подсчитана часть (7 байт) (обратите внимание, что начальный пробел не учитывается).
• Препроцессоры разрешены, только если они являются стандартным вариантом компиляции для вашего языка.
• Окружение зависит от вас, но в интересах обеспечения возможности проверки этого, пожалуйста, придерживайтесь последних (то есть доступных) версий компилятора и операционных систем (и, очевидно, укажите, что вы используете).
• Он должен компилироваться без ошибок (с предупреждениями все в порядке), и сбой компилятора ничего не значит.
• То, что на самом деле делает ваша программа, не имеет значения, хотя и не может быть вредоносным. Это даже не должно быть в состоянии начать.

Пример 1

Программа C

main(){return 1;}

Скомпилировано с Apple LLVM version 7.0.2 (clang-700.1.81)OS X 10.11 (64-разрядная версия):

clang bomb.c -o bomb -pg

Создает файл размером 9228 байт. Общий размер источника составляет 17 + 3 (для -pg) = 20 байт, что легко находится в пределах ограничения по размеру.

Пример 2

Программа Brainfuck:

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

Транспортируется с помощью awib на c:

./awib < bomb.bf > bomb.c

Затем скомпилировано Apple LLVM version 7.0.2 (clang-700.1.81)в OS X 10.11 (64-разрядная версия):

clang bomb.c

Создает файл размером 8464 байта. Общий ввод здесь составляет 143 байта (поскольку @lang_cпо умолчанию для awib его не нужно добавлять в исходный файл, и нет никаких специальных флагов ни для одной из команд).

Также обратите внимание, что в этом случае размер временного файла bomb.c составляет 802 байта, но это не учитывает ни исходный размер, ни выходной размер.

Финальная нота

Если будет получен вывод более 4 ГБ (возможно, если кто-то найдет полный препроцессор Тьюринга), конкуренция будет за самый маленький источник, который создает файл, по крайней мере, такого размера (просто непрактично проверять представления, которые становятся слишком большими) ,

C, (14 + 15) = 29 байт источника, 17 179 875 837 (16 ГБ) байт исполняемого файла

Спасибо @viraptor за 6 байтов.

Спасибо @hvd за 2 байта и размер исполняемого файла x4.

Это определяет mainфункцию как большой массив и инициализирует ее первый элемент. Это заставляет GCC хранить весь массив в результирующем исполняемом файле.

Поскольку этот массив больше 2 ГБ, нам необходимо предоставить -mcmodel=mediumфлаг для GCC. Дополнительные 15 байтов включены в счет согласно правилам.

main[-1u]={1};

Не ожидайте, что этот код сделает что-нибудь приятное при запуске.

Компилировать с:

gcc -mcmodel=medium cbomb.c -o cbomb

Мне потребовалось некоторое время, чтобы приступить к тестированию предложения @ hvd - и найти машину с достаточным количеством сока, чтобы справиться с ней. В конце концов я обнаружил старую непроизводительную виртуальную машину RedHat 5.6 с 10 ГБ ОЗУ, 12 ГБ подкачки и / tmp, установленную на большой локальный раздел. Версия GCC 4.1.2. Общее время компиляции около 27 минут.

Из-за загрузки ЦП и ОЗУ я рекомендую не делать эту компиляцию на любой машине, связанной с производством .

C #, около 1 минуты для компиляции, 28MB выходной двоичный файл:

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

Добавление большего количества Y увеличит размер в геометрической прогрессии.

Объяснение Pharap по запросу @Odomontois:

Этот ответ злоупотребляет параметрами наследования и типа для создания рекурсии. Чтобы понять, что происходит, проще сначала упростить проблему. Рассмотрим class X<A> { class Y : X<Y> { Y y; } }, который генерирует общий класс X<A>, который имеет внутренний класс Y. X<A>.Yнаследует X<Y>, следовательно, X<A>.Yтакже имеет внутренний класс Y, который затем X<A>.Y.Y. В этом случае также имеется внутренний класс Y, и у этого внутреннего класса Yесть внутренний класс Yи т. Д. Это означает, что вы можете использовать область разрешения ( .) до бесконечности, и каждый раз, когда вы его используете, компилятор должен выводить другой уровень наследования и параметризацию типа. ,

При добавлении дополнительных параметров типа работа, которую должен выполнять компилятор на каждом этапе, дополнительно увеличивается.

Рассмотрим следующие случаи:
В class X<A> { class Y : X<Y> { Y y;} }типе param Aесть тип X<A>.Y.
В class X<A> { class Y : X<Y> { Y.Y y;} }типе param Aесть тип X<X<A>.Y>.Y.
В class X<A> { class Y : X<Y> { Y.Y.Y y;} }типе param Aесть тип X<X<X<A>.Y>.Y>.Y.
В class X<A,B> { class Y : X<Y,Y> { Y y;} }типе param Aесть X<A,B>.Yи Bесть X<A,B>.Y.
В class X<A> { class Y : X<Y> { Y.Y y;} }типе param Aесть X<X<A,B>.Y, X<A,B>.Y>.Yи Bесть X<X<A,B>.Y, X<A,B>.Y>.Y.
В class X<A> { class Y : X<Y> { Y.Y.Y y;} }типе param Aесть X<X<X<A,B>.Y, X<A,B>.Y>.Y, X<X<A,B>.Y, X<A,B>.Y>.Y>.Yи Bесть X<X<X<A,B>.Y, X<A,B>.Y>.Y, X<X<A,B>.Y, X<A,B>.Y>.Y>.Y.

После этой модели, можно представить только ¹ работы компилятор должен сделать , чтобы вывести , что Aк Eв Y.Y.Y.Y.Y.Y.Y.Y.Yв определении 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;}}.

¹ Вы можете понять это, но вам нужно много терпения, и intellisense здесь вам не поможет.

Python 3, 13-байтовый источник, 9,057,900,463 байт (8,5 ГБ) .pyc-файл

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

Изменить : Изменил код на версию выше после того, как я понял, правила говорят, что размер вывода за 4 ГБ не имеет значения, и код для этого немного короче; Предыдущий код - и, что более важно, объяснение - можно найти ниже.

Python 3, 16-байтовый источник,> 32 ТБ .pyc-файл (если у вас достаточно памяти, места на диске и терпения)

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

Пояснение: Python 3 делает постоянное сворачивание, и вы быстро получаете большие числа с экспонентой. Формат, используемый в файлах .pyc, хранит длину целочисленного представления с использованием 4 байтов, хотя в действительности ограничение кажется более похожим 2**31, поэтому при использовании только экспоненты для генерации одного большого числа ограничение, как представляется, создает 2 ГБ. PyC-файл из 8-байтового источника. ( 19**8немного стесняется 8*2**31, поэтому 1<<19**8имеет двоичное представление чуть менее 2 ГБ; умножение на восемь происходит потому, что нам нужны байты, а не биты)

Тем не менее, кортежи также являются неизменяемыми, и умножение кортежа также постоянно сворачивается, поэтому мы можем дублировать этот двоичный объект объемом 2 ГБ столько раз, сколько мы хотим, по крайней мере, до 2**31, вероятно, раз. 4**7, Чтобы добраться до 32 Тб был выбран только потому , что это был первый показатель я мог бы найти , что побить предыдущий 16TB ответ.

К сожалению, с памятью, которая у меня есть на моем собственном компьютере, я мог проверить это только с множителем 2, т.е. (1<<19**8,)*2, который сгенерировал файл объемом 8,5 ГБ, который, я надеюсь, демонстрирует реалистичность ответа (т. е. размер файла не ограничен 2 ** 32 = 4 ГБ).

Кроме того, я понятия не имею, почему размер файла, который я получил при тестировании, составлял 8,5 ГБ вместо ожидаемого 4 ГБ, а файл достаточно большой, и в данный момент мне не хочется возиться с ним.

Если будет получен вывод более 4 ГБ (возможно, если кто-то найдет полный препроцессор Тьюринга), то конкуренция будет за самый маленький источник, который создает файл, по крайней мере, такого размера (просто непрактично проверять представления, которые становятся слишком большими) ,

«Шаблон Haskell» позволяет генерировать код на Haskell во время компиляции с использованием Haskell и, следовательно, является полным препроцессором Тьюринга.

Вот моя попытка, параметризованная произвольным числовым выражением FOO:

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

Магия - это код внутри «сращивания» $(...). Это будет выполнено во время компиляции, чтобы сгенерировать AST на Haskell, который внедряется в AST программы вместо соединения.

В этом случае мы создаем простой AST, представляющий литерал 0, мы повторяем это FOOвремя, чтобы создать список, а затем используем его ListEиз Language.Haskell.THмодуля, чтобы превратить этот список AST в один большой AST, представляющий литерал [0, 0, 0, 0, 0, ...].

Полученная программа эквивалентна main = print [0, 0, 0, ...]с FOOповторениями 0.

Чтобы скомпилировать в 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

Это весит 83 байта (66 для кода на Haskell и 17 для -XTemplateHaskellаргумента) плюс длина FOO.

Мы можем избежать аргумента компилятора и просто скомпилировать ghc, но мы должны поместить {-# LANGUAGE TemplateHaskell#-}в начало, что увеличивает размер кода до 97 байт.

Вот несколько примеров выражений FOOи размер получаемого двоичного файла:

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

У меня закончилась компиляция с ОЗУ (2^20).

Мы также можем сделать бесконечный список, используя repeatвместо replicate FOO, но это предотвращает остановку компилятора;)

C ++, 250 + 26 = 276 байт

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;

Это функция Аккермана, реализованная в шаблонах. Я не могу скомпилировать h=a<4,2>::n;на моей маленькой (6 ГБ) машине, но мне удалось h=a<3,14>получить 26M выходной файл. Вы можете настроить константы так, чтобы они превышали пределы вашей платформы - см. Ссылку в статье в Википедии.

Требует наличия -gфлага GCC (поскольку все символы отладки фактически занимают все пространство) и глубины шаблона больше, чем по умолчанию. Моя строка компиляции закончилась как

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

Информация о платформе

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

ASM, 61 байт (29 байт источника, 32 байта для флагов), 4 294 975 320 байт исполняемого файла

.globl main
main:
.zero 1<<32

Компилировать с gcc the_file.s -mcmodel=large -Wl,-fuse-ld=gold

Вот мой ответ C от 2005 года. Если бы у вас было 16 ТБ ОЗУ, то получилось бы 16 ТБ двоичного файла (у вас его нет).

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

Простой старый препроцессор C: 214 байтов, 5 МБ на выходе

Вдохновленный моим настоящим препроцессором провал здесь .

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

Эксперименты показывают, что каждый уровень #defines будет (как и ожидалось) сделать выход примерно в десять раз больше. Но так как этот пример занял больше часа, я никогда не переходил к «G».

Java, исходный код 450 + 22 = 472 байта, файл класса ~ 1 ГБ

B.java (версия для гольфа, предупреждение во время компиляции)

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 (негольфированная версия)

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

компиляция

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

объяснение

Эта бомба использует процессоры аннотаций. Нужно 2 прохода для компиляции. Первый проход строит класс процессора B. Во время второго прохода процессор создает новый исходный файл C.javaи компилирует его вC.class с размером1,073,141,162 байтов.

Есть несколько ограничений при попытке создать большой файл класса:

• Создание идентификаторов длиной более 64 КБ приводит к: error: UTF8 representation for string "iiiiiiiiiiiiiiiiiiii..." is too long for the constant pool .
• Создание более чем 64 тыс. Переменных / функций приводит к: error: too many constants
• Существует также ограничение в размере около 64 КБ для размера кода функции.
• Похоже, что в компиляторе java есть общий предел (ошибка?) Около 1 ГБ для .classфайла. Если я увеличу 16380до16390 в приведенном выше коде, компилятор никогда не вернется.
• Существует также ограничение в 1 ГБ для .javaфайла. Увеличение 16380до 16400в приведенном выше коде приводит к: с An exception has occurred in the compiler (1.8.0_66). Please file a bug ...последующим java.lang.IllegalArgumentException.

C, 26-байтовый источник, 2 139 103 367 байт, допустимая программа

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

Скомпилировано с использованием: gcc cbomb.c -o cbomb(gcc версии 4.6.3, Ubuntu 12.04, ~ 77 секунд)

Я подумала, что попытаюсь увидеть, насколько велика я могла бы создать правильную программу без использования каких-либо параметров командной строки. Я получил идею из этого ответа: https://codegolf.stackexchange.com/a/69193/44946 от Digital Trauma. Смотрите комментарии там, почему это компилируется.

Как это работает: The constубирает флаг записи со страниц в сегменте, поэтому можно выполнить main. 195 машинный код Intel для возврата. А поскольку архитектура Intel имеет младший порядок, это первый байт. Программа завершит работу с любым кодом запуска, записанным в регистре eax, с вероятностью 0.

Это всего около 2 гигабайт, потому что компоновщик использует 32-битные значения со знаком для смещений. Это на 8 мегабайт меньше, чем 2 гигабайта, потому что компилятору / компоновщику нужно немного места для работы, и это самое большое, что я мог получить без ошибок компоновщика - ymmv.

Бу , 71 байт. Время компиляции: 9 минут. Исполняемый файл 134,222,236 байт

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

Использует макрос R(для повторения), чтобы заставить компилятор умножить оператор приращения произвольное число раз. Никаких специальных флагов компилятора не требуется; просто сохраните файл как bomb.booи вызовите компилятор booc bomb.booдля его сборки.

Kotlin , 90-байтовый источник, 177416 байт (173 КБ), скомпилированный двоичный файл JVM

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

Технически, вы можете сделать это еще дольше, вложив выражение дальше. Однако компилятор вылетает с StackOverflowошибкой, если вы увеличиваете рекурсию.

C ++, 214 байт (специальных параметров компиляции не требуется)

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

Это довольно простая двумерная рекурсия шаблонов (глубина рекурсии определяется как квадратный корень из общего числа выпущенных шаблонов, поэтому не превышает пределов платформы) с небольшим количеством статических данных в каждом.

Сгенерированный объектный файл g++ 4.9.3 x86_64-pc-cygwinимеет размер 2567355421 байт (2,4 ГБ).

Увеличение начального значения выше 80 нарушает работу ассемблера cygwin gcc (слишком много сегментов).

Кроме того, 99999может быть заменен 9<<19или подобен для увеличения размера без изменения исходного кода ... но я не думаю, что мне нужно больше места на диске, чем у меня уже есть;)

Scala - источник 70 байт, результат 22980842 байт (после фляги)

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

В результате получается 9 ⁵ (около 59 000) файлов специализированных классов, которые упаковываются в банку размером около 23 МБ. В принципе, вы можете продолжать, если у вас есть файловая система, которая может обрабатывать столько файлов и достаточно памяти.

(Если должна быть включена команда jar, это 82 байта.)

С, 284 байта + 2 для -cin gcc bomb.c -o bomb.o -c; вывод: 2 147 484 052 байта

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

Бу, намного больше, чем вы можете ожидать от этого

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

Тетрационная бомба