(Anti-)Programmierwettbewerb

Firefighter

Werner Salomon schrieb:

@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?

Wie wär's mit

int main;

?

SeppJ

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

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

Ich bin Matrix... schrieb:

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.

Meine Variante, des derefenzierten Unsinns...

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

Hab allerdings nur den gcc ausprobieren können.

Grueßle

Werner Salomon

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.

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

Werner Salomon

camper schrieb:

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

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

Werner Salomon schrieb:

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.

LordJaxom

Werner Salomon schrieb:

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.

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

#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

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

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

camper schrieb:

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«

camper

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.

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

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

Sone schrieb:

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: 

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

Encypruon

Sone schrieb:

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

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 :p

Athar

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

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*