Der Gewinner darf Bug-Reports schreiben :p

int main(){main();}

in den Ring. Oder meinst du legale Programme, die fälschlicherweise abstürzen?

meins ist länger - stürzt aber schneller ab

struct S { int m() { return a; } int a; };
int main()
{
    int* i=0;
    return ((S*)++i)->m();
}

gibt auf VS10 keine Warnings aus (ist das auch Bedingung?)

Gruß
Werner

Ich schmeiße mal

int main(){main();}

in den Ring. Oder meinst du legale Programme, die fälschlicherweise abstürzen?

Jeder Input soll als legal betrachtet werden.
Gemeint sind aber Abstürze o.ä. des Compilers. Wenn das produzierte Programm abstürzt, ist das nicht so interessant, insb. wenn es sowieso UB hat.
Wenn der Compiler abstürzt, liegt schließlich in jedem Fall unabhängig vom Input ein Bug vor.
Beschränkt werden sollte sich aber auf die jeweils aktuellste (Release-)Version eines Compilers.
P.S. Bug-Tracker zu durchsuchen ist unsportlich.

main.cpp:

#include "basic.h"

int main()
{
}

basic.h:

int a;
#include "basic.h"

Wenn ich int a; weglasse meckert er nach ner Weile, wenn nicht, dann landet er in ner Endlosschleife. Hab nicht probiert, ob er iwann abstürzt.

@SeppJ: gute Idee

meins ist länger - stürzt aber schneller ab

struct S { int m() { return a; } int a; };
int main()
{
    int* i=0;
    return ((S*)++i)->m();
}

gibt auf VS10 keine Warnings aus (ist das auch Bedingung?)

Gruß
Werner

Ick raffe nich was du da machst Werner. Was soll ((S*)++i) das denn sein?

int main;

?

Ick raffe nich was du da machst Werner. Was soll ((S*)++i) das denn sein?

Das ist die alte C-Schreibweise für

reinterpret_cast<S*>(++i)

Es ging hier um Kürze, nicht um Lesbarkeit. Den Umweg über das struct hat Werner vermutlich gemacht, weil überclevere Compiler (z.B. gcc) zu offensichtliches undefiniertes Verhalten und wirkungslose Ausdrücke gerne gänzlich wegoptimieren.

Code::Blocks 10.5 hängt sich mit folgendem Code beim Kompilieren/Preprocessor auf:

main.cpp:

#include "basic.h"

int main()
{
}

basic.h:

int a;
#include "basic.h"

Wenn ich int a; weglasse meckert er nach ner Weile, wenn nicht, dann landet er in ner Endlosschleife. Hab nicht probiert, ob er iwann abstürzt.

Mit welchem Compiler?
Die Diagnose dürfte auch in diesem Fall von den Optionen abhängen. Man denke an -pipe - führt zu Redinition - oder -save-temps, das zu zu tief geschachtelter Inklusion führen dürfte.

Ich biete mal

template <typename T>
auto foo(T x) -> decltype(foo(x))
{
    return x;
}

int main()
{
    foo(0);
}

Interessanterweise führt das sowohl bei gcc als auch bei clang zu einem Segfault beim Kompilieren.

int main(){
  (*(void(*)())0)();
}

Hab allerdings nur den gcc ausprobieren können.

Grueßle

Ick raffe nicht was du da machst Werner. Was soll ((S*)++i) das denn sein?

Die Idee ist, das Programm auf ein Stück Memory zugreifen zu lassen, wo es nicht zugreifen darf. Der einfachste Fall wäre z.B.

int* p=0;
    return *p; // hier greift es an der Speicherstelle 0 zu - dass ist nirgends zulässig.

Moderne Compiler 'merken' das aber - entsprechend Analysewerkzeuge vorausgesetzt. D.h. der Rest meines Programms sollte nur dazu diesen, das zu verschleiern.

((S*)++i)

Der (int!-)Pointer auf 0 wird inkrementiert (dann er nicht mehr 0 ist! s.o.) anschließend auf einen Struktur-Pointer gecastet (reinterpret_cast) und dann greif man halt auf einen Member eines nicht existierenden Objekts zu. Das Progrämmchen war auch nur ein Schnellschuss

camper schrieb:

Gemeint sind aber Abstürze o.ä. des Compilers.

womit camper die Messlatte weit nach oben geschoben hat.
Mit dem Visual Studio 6 war das kein Problem - den gefürchteten Fehler C1001 hatte ich zu Hauf. (Bem. zum Link - die Erklärung dahinter ist schlicht gelogen!)

Problem ist nur, dass die Abstürze ziemlich nichtdeterministisch kamen. Ich müsste jetzt alten Code durchwühlen, wo ich entsprechende Kommentare hinterlassen habe. Bei den neueren Compilern wurde es dann schon besser - ich kann mich erinnern, dass mir der VS10 auch schon mal abgenippelt ist, aber ich habe vergessen bei welchem Codestück. Es sind nicht unbedingt exotische Template-Konstruktionen.

Gruß
Werner

Ich biete mal

template <typename T>
auto foo(T x) -> decltype(foo(x))
{
    return x;
}

int main()
{
    foo(0);
}

Interessanterweise führt das sowohl bei gcc als auch bei clang zu einem Segfault beim Kompilieren.

auch 'ne schöne Idee.

führt beim Visual Studio 10 zu

(Zeile 2) fatal error C1045: compiler limit : linkage specifications nested too deeply

IMHO korrektes Verhalten, also kein Absturz.

Gruß
Werner

Gemeint sind aber Abstürze o.ä. des Compilers.

Achso...
ja: wer lesen kann ist klar im Vorteil...ich möchte meinen Beitrag zurückziehen...

führt beim Visual Studio 10 zu

(Zeile 2) fatal error C1045: compiler limit : linkage specifications nested too deeply

IMHO korrektes Verhalten, also kein Absturz.

Ich seh da keine Linkage Specification

Der gerade deklarierte Identifier sollte IMHO in der trailing-type-specifier-seq nicht erlaubt sein. Keine Ahnung, ob das im Standard steht.

int* p=0;
    return *p; // hier greift es an der Speicherstelle 0 zu - dass ist nirgends zulässig.

Denkst Du. Unter HP-UX steht an der Speicherstelle 0 ein Nullbyte, und das steht sogar so in den Spezifikationen des Betriebssystems.

#include <iostream>
using namespace std;
template<int N> struct Foo 
{
    static int bar() 
	{
        return Foo<N - 1>::bar();
    }
};

int main()
{
	Foo<0x7fffffff> foo;

	cout << foo.bar(); // Nur um das Wegoptimiern im Release build zu vermeiden.
}

Der gerade deklarierte Identifier sollte IMHO in der trailing-type-specifier-seq nicht erlaubt sein. Keine Ahnung, ob das im Standard steht.

Da hast du recht, das ist aber bei der Deklaration erst einmal nur bedingt ein Problem. Schließlich ist

foo(x)

ein abhängiger Ausdruck, muss also ggf. noch im Kontext der Instantiierung betrachtet werden, in dem dieses Template dann per ADL gefunden werden könnte (bei einem int-Parameter nat. nicht).

Ich bin, ehrlich gesagt, nicht einmal ganz sicher, unter welche Fehlerkategorie (i.S.d. Standards) dieses Programm fällt.

Ich biete mal

template <typename T>
auto foo(T x) -> decltype(foo(x))
{
    return x;
}

int main()
{
    foo(0);
}

Interessanterweise führt das sowohl bei gcc als auch bei clang zu einem Segfault beim Kompilieren.

g++ (GCC) 4.7.1 20120721 (prerelease)

$ g++ ./main.cpp -omain -std=c++11
./main.cpp: In Ersetzung von »template<class T> decltype (foo(x)) foo(T) [mit T = int]«:
./main.cpp:9:10:   von hier erfordert
./main.cpp:2:6: Fehler: »foo« wurde in diesem Gültigkeitsbereich nicht definiert
./main.cpp:2:6: Anmerkung: empfohlene Alternative:
./main.cpp:2:6: Anmerkung:   »foo«
./main.cpp: In Funktion »int main()«:
./main.cpp:9:10: Fehler: keine passende Funktion für Aufruf von »foo(int)«
./main.cpp:9:10: Anmerkung: Kandidat ist:
./main.cpp:2:6: Anmerkung: template<class T> decltype (foo(x)) foo(T)
./main.cpp:2:6: Anmerkung:  Ersetzung der ermittelten Templateargumente führte zu obigen Fehlern

clang version 3.2 (trunk)

$ clang++ ./main.cpp -omain -std=c++11 -ftemplate-backtrace-limit=3
./main.cpp:2:6: fatal error: recursive template instantiation exceeded maximum depth of 512
auto foo(T x) -> decltype(foo(x))
     ^
./main.cpp:2:6: note: while substituting deduced template arguments into function template 'foo' [with T = int]
auto foo(T x) -> decltype(foo(x))
     ^
./main.cpp:2:6: note: while substituting deduced template arguments into function template 'foo' [with T = int]
auto foo(T x) -> decltype(foo(x))
     ^
./main.cpp:2:6: note: (skipping 510 contexts in backtrace; use -ftemplate-backtrace-limit=0 to see all)
./main.cpp:2:6: note: while substituting deduced template arguments into function template 'foo' [with T = int]
auto foo(T x) -> decltype(foo(x))
     ^
./main.cpp:9:5: error: no matching function for call to 'foo'
    foo(0);
    ^~~
./main.cpp:2:6: note: candidate template ignored: substitution failure [with T = int]: use of undeclared identifier 'foo'
auto foo(T x) -> decltype(foo(x))
     ^                    ~~~
2 errors generated.

Beides keine Abstürze

Allerdings

./main.cpp:2:6: Fehler: »foo« wurde in diesem Gültigkeitsbereich nicht definiert
./main.cpp:2:6: Anmerkung: empfohlene Alternative:
./main.cpp:2:6: Anmerkung:   »foo«

pyhax schrieb:

g++ (GCC) 4.7.1 20120721 (prerelease)

Oh, hatte versehentlich mit 4.6.3 getestet.

pyhax schrieb:

clang version 3.2 (trunk)

gut zu wissen. Diese Version ist allerdings noch nicht freigegeben.

clang++ ./test.cpp -otest -std=c++11 -v
clang version 3.1 (branches/release_31)
Target: x86_64-pc-linux-gnu
Thread model: posix
 "/usr/bin/clang" -cc1 -triple x86_64-pc-linux-gnu -emit-obj -mrelax-all -disable-free -disable-llvm-verifier -main-file-name test.cpp -mrelocation-model static -mdisable-fp-elim -masm-verbose -mconstructor-aliases -munwind-tables -target-cpu x86-64 -target-linker-version 2.22 -momit-leaf-frame-pointer -v -resource-dir /usr/bin/../lib/clang/3.1 -fmodule-cache-path /var/tmp/clang-module-cache -internal-isystem /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/include/g++-v4 -internal-isystem /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/include/g++-v4/x86_64-pc-linux-gnu -internal-isystem /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/include/g++-v4/backward -internal-isystem /usr/local/include -internal-isystem /usr/bin/../lib/clang/3.1/include -internal-externc-isystem /include -internal-externc-isystem /usr/include -std=c++11 -fdeprecated-macro -fdebug-compilation-dir /home/matthias -ferror-limit 19 -fmessage-length 158 -mstackrealign -fgnu-runtime -fobjc-runtime-has-arc -fobjc-runtime-has-weak -fobjc-fragile-abi -fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/test-9u4o7q.o -x c++ ./test.cpp
clang -cc1 version 3.1 based upon LLVM 3.1 default target x86_64-pc-linux-gnu
ignoring nonexistent directory "/usr/local/include"
ignoring nonexistent directory "/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/include/g++-v4
 /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/include/g++-v4/x86_64-pc-linux-gnu
 /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/include/g++-v4/backward
 /usr/bin/../lib/clang/3.1/include
 /usr/include
End of search list.
clang: error: unable to execute command: Segmentation fault
clang: error: clang frontend command failed due to signal (use -v to see invocation)
clang: note: diagnostic msg: Please submit a bug report to http://llvm.org/bugs/ and include command line arguments and all diagnostic information.
clang: note: diagnostic msg: Preprocessed source(s) and associated run script(s) are located at:
clang: note: diagnostic msg: /tmp/test-nNEpCD.ii
clang: note: diagnostic msg: /tmp/test-nNEpCD.sh

schnief. Wie waers damit?

Edit: Camper, was ist eig. mit ROT13?

template<int ...i>
void foo()
{
        foo<i..., i..., i..., i..., i...>();
}
 
int main()
{
    foo<0>();
}

schnief. Wie waers damit?

Edit: Camper, was ist eig. mit ROT13?

Funktioniert mit GCC 4.7.1:

virtual memory exhausted: Nicht genügend Hauptspeicher verfügbar

Clang (3.2)

clang version 3.2 (trunk)
Target: i386-pc-linux-gnu
Thread model: posix
 "/usr/bin/clang-3.2" -cc1 -triple i386-pc-linux-gnu -emit-obj -mrelax-all -disable-free -disable-llvm-verifier -main-file-name main.cpp -mrelocation-model static -mdisable-fp-elim -fmath-errno -masm-verbose -mconstructor-aliases -fuse-init-array -target-cpu pentium4 -momit-leaf-frame-pointer -v -resource-dir /usr/bin/../lib/clang/3.2 -fmodule-cache-path /var/tmp/clang-module-cache -internal-isystem /usr/lib/gcc/i686-pc-linux-gnu/4.7.1/../../../../include/c++/4.7.1 -internal-isystem /usr/lib/gcc/i686-pc-linux-gnu/4.7.1/../../../../include/c++/4.7.1/i686-pc-linux-gnu -internal-isystem /usr/lib/gcc/i686-pc-linux-gnu/4.7.1/../../../../include/c++/4.7.1/backward -internal-isystem /usr/local/include -internal-isystem /usr/bin/../lib/clang/3.2/include -internal-externc-isystem /include -internal-externc-isystem /usr/include -std=c++11 -fdeprecated-macro -fdebug-compilation-dir /tmp -ferror-limit 19 -fmessage-length 161 -mstackrealign -fobjc-runtime=gcc -fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/main-IL06Bv.o -x c++ main.cpp
clang -cc1 version 3.2 based upon LLVM 3.2svn default target i386-pc-linux-gnu
ignoring nonexistent directory "/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/i686-pc-linux-gnu/4.7.1/../../../../include/c++/4.7.1
 /usr/lib/gcc/i686-pc-linux-gnu/4.7.1/../../../../include/c++/4.7.1/i686-pc-linux-gnu
 /usr/lib/gcc/i686-pc-linux-gnu/4.7.1/../../../../include/c++/4.7.1/backward
 /usr/local/include
 /usr/bin/../lib/clang/3.2/include
 /usr/include
End of search list.
Stack dump:
0.      Program arguments: /usr/bin/clang-3.2 -cc1 -triple i386-pc-linux-gnu -emit-obj -mrelax-all -disable-free -disable-llvm-verifier -main-file-name main.cpp -mrelocation-model static -mdisable-fp-elim -fmath-errno -masm-verbose -mconstructor-aliases -fuse-init-array -target-cpu pentium4 -momit-leaf-frame-pointer -v -resource-dir /usr/bin/../lib/clang/3.2 -fmodule-cache-path /var/tmp/clang-module-cache -internal-isystem /usr/lib/gcc/i686-pc-linux-gnu/4.7.1/../../../../include/c++/4.7.1 -internal-isystem /usr/lib/gcc/i686-pc-linux-gnu/4.7.1/../../../../include/c++/4.7.1/i686-pc-linux-gnu -internal-isystem /usr/lib/gcc/i686-pc-linux-gnu/4.7.1/../../../../include/c++/4.7.1/backward -internal-isystem /usr/local/include -internal-isystem /usr/bin/../lib/clang/3.2/include -internal-externc-isystem /include -internal-externc-isystem /usr/include -std=c++11 -fdeprecated-macro -fdebug-compilation-dir /tmp -ferror-limit 19 -fmessage-length 161 -mstackrealign -fobjc-runtime=gcc -fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/main-IL06Bv.o -x c++ main.cpp 
1.      <eof> parser at end of file
2.      main.cpp:2:6: instantiating function definition 'foo'
3.      main.cpp:2:6: instantiating function definition 'foo'
4.      main.cpp:2:6: instantiating function definition 'foo'
5.      main.cpp:2:6: instantiating function definition 'foo'
6.      main.cpp:2:6: instantiating function definition 'foo'
7.      main.cpp:2:6: instantiating function definition 'foo'
8.      main.cpp:2:6: instantiating function definition 'foo'
9.      main.cpp:2:6: instantiating function definition 'foo'
10.     main.cpp:2:6: instantiating function definition 'foo'
11.     main.cpp:2:6: instantiating function definition 'foo'
clang-3: error: unable to execute command: Segmentation fault
clang-3: error: clang frontend command failed due to signal (use -v to see invocation)
clang version 3.2 (trunk)
Target: i386-pc-linux-gnu
Thread model: posix
clang-3: note: diagnostic msg: PLEASE submit a bug report to  and include the crash backtrace, preprocessed source, and associated run script.
clang-3: note: diagnostic msg: 
********************

PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang-3: note: diagnostic msg: /tmp/main-jJJ2qI.cpp
clang-3: note: diagnostic msg: /tmp/main-jJJ2qI.sh
clang-3: note: diagnostic msg: 

********************

template<int ...i>
void foo()
{
        foo<i..., i..., i..., i..., i...>();
}
 
int main()
{
    foo<0>();
}

schnief. Wie waers damit?

Edit: Camper, was ist eig. mit ROT13?

Das Ding ist schlichtweg teuflisch. Bei mir (unter Ubuntu (Linux) 11.10) hat der Compiler (gcc) in ein paar sek. 4,9GiB Ram belegt, was die komplette grafische Oberfläche zum erliegen brachte. Um den PC wieder ins Leben zu rufen, musste ich mit meinem Handy per SSH den Compiler killen.

Das Ding ist schlichtweg teuflisch. Bei mir (unter Ubuntu (Linux) 11.10) hat der Compiler (gcc) in ein paar sek. 4,9GiB Ram belegt, was die komplette grafische Oberfläche zum erliegen brachte. Um den PC wieder ins Leben zu rufen, musste ich mit meinem Handy per SSH den Compiler killen.

Da arbeitet jemand ohne ulimit :p

Das Ding ist schlichtweg teuflisch. Bei mir (unter Ubuntu (Linux) 11.10) hat der Compiler (gcc) in ein paar sek. 4,9GiB Ram belegt, was die komplette grafische Oberfläche zum erliegen brachte. Um den PC wieder ins Leben zu rufen, musste ich mit meinem Handy per SSH den Compiler killen.

Da musste ich an das hier denken.
Hätte es nicht gereicht, zu einem anderen TTY zu wechseln?

Das Ding ist schlichtweg teuflisch. Bei mir (unter Ubuntu (Linux) 11.10) hat der Compiler (gcc) in ein paar sek. 4,9GiB Ram belegt, was die komplette grafische Oberfläche zum erliegen brachte. Um den PC wieder ins Leben zu rufen, musste ich mit meinem Handy per SSH den Compiler killen.

höhö^^ *g*