(Anti-)Programmierwettbewerb

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*

Sone

Wie weit vorn steh ich? :p
Ich arbeite noch an einer anderen Methode.

pyhax

Noch etwas für den GCC:

int main() {
decltype(static_cast<int(*)(int*)>(0) );
}

$ 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.

gilt sowas auch?

class c{
public:
	c(){
		new c();
	}
};

int main(){
	new c();
}

pyhax

kellerkindanwärter schrieb:

gilt sowas auch?

class c{
public:
	c(){
		new c();
	}
};

int main(){
	new c();
}

Kein Absturz (weder beim GCC noch be clang)

so vllt.

#include <stdio.h>

class c{
	public:
	~c(){
		this->~c();
	}
};

int main(){
	c x;
}