c++.de :: (Anti-)Programmierwettbewerb

camper Mitglied 12:03:23 03.08.2012 Titel:

Aufgabe: erstelle das kürzeste Programm, dass bei mehreren verschiedenen Compilern von verschiedenen Herstellern zu einem ICE/Segfault/Crash etc. führt.

Der Gewinner darf Bug-Reports schreiben

SeppJ Moderator 12:12:31 03.08.2012 Titel:

Ich schmeiße mal

C++:
int main(){main();}

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

Werner Salomon Mitglied 12:20:34 03.08.2012 Titel:

@SeppJ: gute Idee :live:

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

C++:
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

camper Mitglied 12:23:18 03.08.2012 Titel:

SeppJ schrieb:

Ich schmeiße mal

C++:
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.

Ich bin Matrix... Mitglied 12:54:21 03.08.2012 Titel:

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

main.cpp:

C++:
#include "basic.h" int main() { }

basic.h:

C++:
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.

Firefighter Mitglied 12:55:19 03.08.2012 Titel:

Werner Salomon schrieb:

@SeppJ: gute Idee :live:

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

C++:
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?

Unregistrierter

Wie wär's mit

C++:
int main;

?

SeppJ Moderator 13:02:11 03.08.2012 Titel:

Firefighter schrieb:

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

Das ist die alte C-Schreibweise für

C++:
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.

camper Mitglied 13:10:24 03.08.2012 Titel:

Ich bin Matrix... schrieb:

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

main.cpp:

C++:
#include "basic.h" int main() { }

basic.h:

C++:
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

C++:
1 2 3 4 5 6 7 8 9 10	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.

Unregistrierter

Meine Variante, des derefenzierten Unsinns...

C++:
int main(){ ((void()())0)(); }

Hab allerdings nur den gcc ausprobieren können.

Grueßle

Werner Salomon Mitglied 13:21:21 03.08.2012 Titel:

Firefighter schrieb:

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.

C++:
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.

C++:
((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 :cool:

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

Werner Salomon Mitglied 13:28:36 03.08.2012 Titel:

camper schrieb:

Ich biete mal

C++:
1 2 3 4 5 6 7 8 9 10	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

Zitat:

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

IMHO korrektes Verhalten, also kein Absturz.

Gruß
Werner

Unregistrierter

camper schrieb:

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

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

Bashar Mitglied 13:39:33 03.08.2012 Titel:

Werner Salomon schrieb:

führt beim Visual Studio 10 zu

Zitat:

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

IMHO korrektes Verhalten, also kein Absturz.

Ich seh da keine Linkage Specification :confused:

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

LordJaxom Mitglied 13:53:56 03.08.2012 Titel:

Werner Salomon schrieb:

C++:
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.

Unregistrierter

Nicht so kurz wie die bisherigen Vorschläge, dafür hält es den Compiler aber lange beschäftigt (cl rennt seit 10 min hat aber noch nicht aufgegeben

):

Code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16	#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. }

camper Mitglied 15:02:10 03.08.2012 Titel:

Bashar schrieb:

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

C++:
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.

pyhax Mitglied 15:16:07 03.08.2012 Titel:

camper schrieb:

Ich biete mal

C++:
1 2 3 4 5 6 7 8 9 10	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)

Code:
1 2 3 4 5 6 7 8 9 10 11	$ 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)

Code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21	$ 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

Code:
./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«

camper Mitglied 15:26:50 03.08.2012 Titel:

Gut aufgepasst.

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.

Code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22	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

Sone Mitglied 16:56:05 03.08.2012 Titel:

C++:
1 2 3 4 5 6 7 8 9 10	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?

pyhax Mitglied 17:05:09 03.08.2012 Titel:

Sone schrieb:

C++:
1 2 3 4 5 6 7 8 9 10	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:

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

Clang (3.2)

Code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44	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: ******************

Encypruon Mitglied 01:50:09 04.08.2012 Titel:

Sone schrieb:

C++:
1 2 3 4 5 6 7 8 9 10	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.

camper Mitglied 02:16:10 04.08.2012 Titel:

Encypruon schrieb:

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

Athar Mitglied 05:36:08 04.08.2012 Titel:

Encypruon schrieb:

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?

Skym0sh0 Mitglied 10:30:52 04.08.2012 Titel:

Encypruon schrieb:

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*

Sone Mitglied 15:04:11 04.08.2012 Titel:

Wie weit vorn steh ich?

Ich arbeite noch an einer anderen Methode.

pyhax Mitglied 23:49:24 13.08.2012 Titel:

Noch etwas für den GCC:

C++:
int main() { decltype(static_cast<int()(int)>(0) ); }

Code:
$ LANG="C" g++ ./main.cpp -omain -std=c++11 ./main.cpp: In function 'int main()': ./main.cpp:2:37: internal compiler error: in cp_parser_abort_tentative_parse, at cp/parser.c:22878 Please submit a full bug report, with preprocessed source if appropriate. See <https://bugs.archlinux.org/> for instructions.

Unregistrierter

gilt sowas auch?

C++:
1 2 3 4 5 6 7 8 9 10	class c{ public: c(){ new c(); } }; int main(){ new c(); }

pyhax Mitglied 00:19:02 14.08.2012 Titel:

kellerkindanwärter schrieb:

gilt sowas auch?

C++:
1 2 3 4 5 6 7 8 9 10	class c{ public: c(){ new c(); } }; int main(){ new c(); }

Kein Absturz (weder beim GCC noch be clang)

Unregistrierter

so vllt.

C++:
1 2 3 4 5 6 7 8 9 10 11 12	#include <stdio.h> class c{ public: ~c(){ this->~c(); } }; int main(){ c x; }

Swordfish Mitglied 01:28:45 14.08.2012 Titel:

kellerkindanwärter schrieb:

so vllt.

Nö.

hustbaer Mitglied 05:35:38 14.08.2012 Titel:

@kellerkindanwärter
Du scheinst hier was falsch verstanden zu haben: es geht nicht darum dass das generierte Programm crasht, sondern darum dass der Compiler crasht. Und zwar richtig crasht -- also nicht ein kontrolliert Abbruch mit einer Fehlermeldung ala "das schachtelt mir zu tief".

Das Sahnehäubchen wäre dann noch, wenn du das mit einem laut Standard gültigen Programm hinbekommst. Also etwas was laut Standard "well formed" ist, kein UB zur Folge hat etc.

BTW: bei MSVC 6 war schon sowas in der Art ausreichend:

C++:
class foo; class bar {}; typedef bar foo;

Wobei das leider kein Sahnehäubchen hat, und mit MSVC 6 Bugs lockt man auch keinen mehr hinterm Ofen vor.
Sahnehäubchen-Bug, bzw. einen der auch moderne Compiler betrifft hab' ich keinen mehr in Erinnerung, sonst hätte ich schon gepostet.

pyhax Mitglied 11:37:21 14.08.2012 Titel:

Ist mein Bug ein "Sahnehäubchen-Bug" ?

camper Mitglied 12:04:51 14.08.2012 Titel:

pyhax schrieb:

Ist mein Bug ein "Sahnehäubchen-Bug" ?

Der gefällt mir.

Scheint sich um #51908 zu handeln, nur ohne variadic Templates.

hustbaer Mitglied 12:21:52 14.08.2012 Titel:

pyhax schrieb:

Ist mein Bug ein "Sahnehäubchen-Bug" ?

Ich denke schon.
Ist zwar komisch nur typ; zu schreiben, aber erlaubt isses (Deklaration die nix deklariert). Wird vermutlich mit decltype(...); nicht anders sein.
(Wobei es vermutlich auch noch crasht wenn du nen Deklarator dazuschreibst.)

camper Mitglied 12:41:08 14.08.2012 Titel:

hustbaer schrieb:

aber erlaubt isses (Deklaration die nix deklariert).

Ich bin ziemlich sicher, dass das nicht erlaubt ist. Es gibt ein paar Fälle, wo die Deklaration selbst keinen Bezeichner einführt, dann gehört dazu aber immer noch etwas anderes, das das tut (bei anonymen unions mindestens ein Member; und unbenannte Bitfelder sind immer Teil einer Klasse).

berniebutt Mitglied 12:53:10 14.08.2012 Titel:

Was soll dieser Wettbewerb erreichen? :confused:

Code zum Absturz eines Programmes kann jeder schreiben, nicht nur Anfänger. :o)

Einen Code, der mit unterschiedlichen Compilern mal läuft und mal nicht, findet sich immer. Den Compiler absichtlich zum Absturz bringen? :confused:

Ist auch sicher möglich, nur wozu? Die Frage hier erscheint mir wenig interessant zum weiteren Nachdenken.

Rufe den Pizzadienst. Sein Kassencomputer hat kein solches Problem!

hustbaer Mitglied 13:00:59 14.08.2012 Titel:

camper schrieb:

hustbaer schrieb:

aber erlaubt isses (Deklaration die nix deklariert).

Ich bin ziemlich sicher, dass das nicht erlaubt ist. Es gibt ein paar Fälle, wo die Deklaration selbst keinen Bezeichner einführt, dann gehört dazu aber immer noch etwas anderes, das das tut (bei anonymen unions mindestens ein Member; und unbenannte Bitfelder sind immer Teil einer Klasse).

Hm. OK

Crasht der Code noch wenn man nen Deklarator dranschreibt? Wenn ja wäre ja alles in Butter.

@berniebutt
Ach weisste, es gibt immer Dinge die für manche interessant sind, und für andere total doof. Man muss aber nicht überall was dazuschreiben, wo man das doof findet.

otze Mitglied 18:20:04 14.08.2012 Titel:

Berniebutt. Eventuell sind solche Wettbewerbe interessant, weil sie austesten wie gut die Compikler, von denen unglaublich viel auf unseren Systemen abhängt, überhaupt getestet sind. Jeder gefundene Bug erhöht die Sicherheit.

Aber bei dir habe ich eh den Eindruck, dass dich Informatik als Solche nicht sonderlich interessiert

.

pyhax Mitglied 18:29:06 14.08.2012 Titel:

hustbaer schrieb:

camper schrieb:

hustbaer schrieb:

aber erlaubt isses (Deklaration die nix deklariert).

Ich bin ziemlich sicher, dass das nicht erlaubt ist. Es gibt ein paar Fälle, wo die Deklaration selbst keinen Bezeichner einführt, dann gehört dazu aber immer noch etwas anderes, das das tut (bei anonymen unions mindestens ein Member; und unbenannte Bitfelder sind immer Teil einer Klasse).

Hm. OK

Crasht der Code noch wenn man nen Deklarator dranschreibt? Wenn ja wäre ja alles in Butter.

Ja, der crasht noch. Aber es sollte doch kurz sein

(Und ich hatte es auch erst mit Variadic templates, habe dann aber rausgefunden das es auch ohne geht. BTW: Wenn man als Funktionspointertype int(*)(int) nimmt, crasht es nicht. Ebenso wenn man den Cast durch einen C-style cast ersetzt, reinterpret_cast crasht aber

)

berniebutt Mitglied 20:09:35 14.08.2012 Titel:

otze schrieb:

... Eventuell sind solche Wettbewerbe interessant, weil sie austesten wie gut die Compikler, von denen unglaublich viel auf unseren Systemen abhängt, überhaupt getestet sind. Jeder gefundene Bug erhöht die Sicherheit ...

Welche Sicherheit soll denn erhöht werden? Ihr sucht Möglichkeiten einen Compiler zum Abschmieren zu bringen. Wird schwer: der Compiler interpretiert nur Text und versucht nach vorgegebenen Regeln daraus ein ausführbares Programm zu machen. Weil Compiler auch programmiert sind können diese sicher nicht jeden Unsinn erkennen oder abfangen. Die Umsetzung zur exe gelingt oder gelingt nicht.

Bitte zeigen, wie man schon den Compiler mit einem simplen Sourcecode zum Crash führt!

Unregistrierter

berniebutt schrieb:

Weil Compiler auch programmiert sind können diese sicher nicht jeden Unsinn erkennen oder abfangen. Die Umsetzung zur exe gelingt oder gelingt nicht.

Die Theorie des Compilerbaus ist sehr gut verstanden. Die Aussage, dass ein Compiler "nicht jeden Unsinn" erkennen kann, ist somit Quatsch. C++ kratzt an den Grenzen des derzeit praktisch machbaren ob der Komplexität des Standards und einen Compiler zum abschmieren zu bringen ist also sehr wohl interessant.

Wenn man kein Interesse hat, einfach mal die Fresse halten.

Sone Mitglied 20:46:34 14.08.2012 Titel:

berniebutt schrieb:

Bitte zeigen, wie man schon den Compiler mit einem simplen Sourcecode zum Crash führt!

Siehe mein Code. Oder Pyhax'.

hustbaer Mitglied 21:07:17 14.08.2012 Titel:

@berniebutt

Also hier extra für dich ein schönes Beispiel mit dem schönen (gerade noch) aktuellen MSVC 2010:

http://stackoverflow.com/ ....... ile-in-visual-studio-2010

Bzw. google auch selber gerne nach MSVC C1001 oder C1001 ICE.

berniebutt Mitglied 14:07:12 15.08.2012 Titel:

Ich habe die Antworten verstanden: Die Compilerbauer hinken der Komplexität theoretischer Anforderungen gelegentlich hinterher oder schaffen einiges einfach nicht so schnell, was sich theoriebessene Fuzzies ausdenken. Was heisst das nun für die Programmierung? Meine Antwort: Immer auf klare ausgereifte Standards setzen und nur bugfreie Dinge verwenden. War schon immer so!

Wer sein eigenes Programm wegen eines Bugs im Compiler nicht zum laufen bringt ist arm dran und verdient mit seiner Arbeit kein Geld. Der Kunde will ein lauffähiges Programm und nur dafür zahlt er! :eek:

hustbaer Mitglied 22:08:47 15.08.2012 Titel:

@berniebutt
Niemand sagt dass wir bzw. andere Leute die Compiler-Bugs finden unsere/ihre Programme nicht zum Laufen bekommen. Du erfindest hier ein Szenario das einfach nicht real ist.

Was bitte ist schlecht daran Compiler-Bugs zu suchen? Wenn man sie findet kann man sie reporten, und dann können sie gefixt werden.

Das hat auch nichts damit zu tun dass man irgendwelchen total krassen bekloppten Code schreibt, oft stolpert man da einfach so drüber.

Es gibt nunmal einen C++ Standard, und die Compiler sollten sich daran halten. Wenn man mit korrektem Code einen Compiler zum Crashen bringt, dann ist nicht der Programmierer fehlerhaft sondern der Compiler.
Und selbst wenn man mit inkorrektem Code einen Compiler zum Crashen bringt, ist der Compiler fehlerhaft bzw. zumindest minderwertig: er sollte eine (idealerweise verständliche) Fehlermeldung abliefern anstatt einfach nur zu crashen.

Unregistrierter

Moin!
mein gcc 4.5.1 (und der von ideone) stürzen ab:

C++:
#include <vector> int main(){ std::vector<int>{int}; }

War das Produkt einer Kompilierung, bevor ich meinen Gedanken fertig geschrieben habe...

Ich denke nicht dass das wirklich Compilerübergreifend ist. Da ist doch wohl ein Syntaxfehler. Comeau online gibt sich auch keine Blöße.

Was sagen denn Eure Compiler so? Besonders neuere gcc.
Wenn es noch nicht gefixt wurde könnte man dem ja auf den Grund gehen...

Sone Mitglied 21:57:56 18.08.2012 Titel:

GCC 4.8 developer release schrieb:

C:...\C(++) Saves\TEMPS\TEMP.cxx||In function 'int main()':|
C:\...\C(++) Saves\TEMPS\TEMP.cxx|4|error: no matching function for call to 'std::vector<int>::vector(<brace-enclosed initializer list>)'|
C:\...\C(++) Saves\TEMPS\TEMP.cxx|4|note: candidates are:|
.....

Unregistrierter

Na das ging ja fix...
:live: