Вступ

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

Виклик

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

Правила

Гаразд, тому є кілька важливих роз’яснень, визначень та обмежень;

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

Приклад 1

Програма С

main(){return 1;}

Скомпільовано Apple LLVM version 7.0.2 (clang-700.1.81)в ОС X 10.11 (64-розрядна):

clang bomb.c -o bomb -pg

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

Приклад 2

Програма Brainfuck:

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

Транспільовано з wiib на c:

./awib < bomb.bf > bomb.c

Потім компілюється з Apple LLVM version 7.0.2 (clang-700.1.81)ОС 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 VM з 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тощо. Це означає, що ви можете використовувати роздільну здатність ( .) ad infinitum, і кожен раз, коли ви використовуєте, компілятор повинен виводити інший рівень спадкування та параметризацію типу .

Додаючи додаткові параметри типу, робота, яку повинен виконувати компілятор на кожному етапі, ще більше збільшується.

Розглянемо наступні випадки:
В class X<A> { class Y : X<Y> { Y y;} }типу парам Aмає тип X<A>.Y.
В class X<A> { class Y : X<Y> { Y.Y y;} }типу парах Aмають тип X<X<A>.Y>.Y.
В class X<A> { class Y : X<Y> { Y.Y.Y y;} }типу парах Aмають тип X<X<X<A>.Y>.Y>.Y.
У class X<A,B> { class Y : X<Y,Y> { Y y;} }типі пари Aце X<A,B>.Yі Bє X<A,B>.Y.
У class X<A> { class Y : X<Y> { Y.Y y;} }типі пари 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;} }типі пари 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;}}.

¹ Ви могли це зрозуміти, але вам знадобиться багато терпіння, і інтелігенція тут вам не допоможе.

Python 3, 13-байтне джерело, 9,057,900,463 байт (8,5GiB) .pyc-файл

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

Редагувати : Змінив код на версію вище, після того як я зрозумів, що правило, розмір виходу понад 4GiB не має значення, і код для цього стає настільки трохи коротшим; Попередній код - а ще важливіше пояснення - можна знайти нижче.

Python 3, 16-байтне джерело,> 32TB .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|])

Магія - це код всередині "сплайса" $(...). Це буде виконано під час компіляції, щоб генерувати Haskell AST, який прищеплюється до 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;

Це функція Ackermann, реалізована в шаблонах. Я не в змозі компілювати h=a<4,2>::n;на моїй маленькій машині (6 Гб), але мені вдалося h=a<3,14>отримати вихідний файл 26 М. Ви можете налаштувати константи, щоб досягти меж вашої платформи - для ознайомлення дивіться пов'язану статтю у Вікіпедії.

Потрібен -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байтів.

При спробі створити файл великого класу є кілька обмежень:

• Створення ідентифікаторів більше , ніж близько 64k результатів: error: UTF8 representation for string "iiiiiiiiiiiiiiiiiiii..." is too long for the constant pool.
• Створення більш ніж приблизно 64 к змінних / функцій призводить до: error: too many constants
• Існує також обмеження приблизно 64 к для розміру коду функції.
• Здається, загальний ліміт (помилка?) У компіляторі Java близько 1 Гб для .classфайлу. Якщо я збільшую 16380до16390 вищевказаного коду, компілятор ніколи не повертається.
• Також для .javaфайлу обмежено близько 1 ГБ . Збільшення 16380до 16400вищевказаного коду призводить до: з An exception has occurred in the compiler (1.8.0_66). Please file a bug ...наступним a 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. Дивіться коментарі до того, чому це складається.

Як це працює: constВидаляє прапор запису зі сторінок у сегменті, тому головне може бути виконане. Це 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(для Repeat), щоб змусити компілятор множити оператор приросту довільну кількість разів. Не потрібні спеціальні прапори компілятора; просто збережіть файл як bomb.booі викликайте компілятор, booc bomb.booщоб створити його.

Котлін , джерело 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 байти.)

C, 284 байт + 2 для -cвходу 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

Пітон 3:

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

Тетраційна бомба