(Anti-)Programmierwettbewerb



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



  • 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.
    }
    

  • Mod

    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.



  • 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«
    

    😃


  • Mod

    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
    


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



  • 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: 
    
    ********************
    


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


  • Mod

    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



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



  • 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*



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



  • 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();
    }
    


  • 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;
    }
    


  • kellerkindanwärter schrieb:

    so vllt. 😞

    Nö.



  • @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:

    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.



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


Anmelden zum Antworten