4 ms·

I just tried the C version and it compiles and exits gracefully with gcc 4.2.1.

kevinnk 14y ago
The example the article gives isn't a general C problem, it's a common bug in some (mostly older) C/C++ compilers. As you point out GCC does not have this bug.
- haberman 14y ago
  It's not a bug, it's intended to be undefined behavior; see http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#614 http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html... (issue 1450)
  - mikeash 14y ago
    Regardless of undefined behavior, it should not crash the compiler.
    - haberman 14y ago
      Ah, I missed that it can crash the tcc compiler. Yeah, that's a bug.
      - mikeash 14y ago
        Probably easy to miss. One really does not expect the compiler to crash on code like that.
ThisIsADogHello 14y ago
Similarly, I tried the pgsql example on 8.4.13, although on FreeBSD rather than Windows like they suggest, and all I got was: ERROR: floating-point exception DETAIL: An invalid floating-point operation was signaled. This probably means an out-of-range result or an invalid operation, such as division by zero.
haberman 14y ago
That's probably because the code in the article uses compile-time constants as operands. Try this one and pass "-1" as the command-line parameter: int main(int argc, char *argv[]) { return (1LL << 63) / atoi(argv[1]); } Note that this issue has been written about before by Tavis Ormandy: http://my.opera.com/taviso/blog/show.dml/639454 http://my.opera.com/taviso/blog/show.dml/639454
- huhsamovar 14y ago
  Floating point exception: 8
derleth 14y ago
Here's the LLVM code that clang-3.0-6ubuntu3 emits: define i64 @crash() nounwind uwtable readnone optsize { ret i64 undef } In machine code terms, on x86-64 this turns into a function composed entirely of the ret opcode. gcc-4.6 adds an xor eax, eax before the ret.
afhof 14y ago
Would you mind posting the output of gcc -S ? Also, what optimization level did you run with?
- huhsamovar 14y ago
  No optimisation. http://pastebin.com/NpUExgA2 http://pastebin.com/NpUExgA2

The example the article gives isn't a general C problem, it's a common bug in some (mostly older) C/C++ compilers. As you point out GCC does not have this bug.

haberman 14y ago
It's not a bug, it's intended to be undefined behavior; see http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#614 http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html... (issue 1450)
- mikeash 14y ago
  Regardless of undefined behavior, it should not crash the compiler.
  - haberman 14y ago
    Ah, I missed that it can crash the tcc compiler. Yeah, that's a bug.
    - mikeash 14y ago
      Probably easy to miss. One really does not expect the compiler to crash on code like that.

ThisIsADogHello 14y ago

Similarly, I tried the pgsql example on 8.4.13, although on FreeBSD rather than Windows like they suggest, and all I got was: ERROR: floating-point exception DETAIL: An invalid floating-point operation was signaled. This probably means an out-of-range result or an invalid operation, such as division by zero.

haberman 14y ago

That's probably because the code in the article uses compile-time constants as operands. Try this one and pass "-1" as the command-line parameter: int main(int argc, char *argv[]) { return (1LL << 63) / atoi(argv[1]); } Note that this issue has been written about before by Tavis Ormandy: http://my.opera.com/taviso/blog/show.dml/639454 http://my.opera.com/taviso/blog/show.dml/639454

huhsamovar 14y ago
Floating point exception: 8

derleth 14y ago

Here's the LLVM code that clang-3.0-6ubuntu3 emits: define i64 @crash() nounwind uwtable readnone optsize { ret i64 undef } In machine code terms, on x86-64 this turns into a function composed entirely of the ret opcode. gcc-4.6 adds an xor eax, eax before the ret.

afhof 14y ago

Would you mind posting the output of gcc -S ? Also, what optimization level did you run with?

huhsamovar 14y ago
No optimisation. http://pastebin.com/NpUExgA2 http://pastebin.com/NpUExgA2