4 ms·

Interesting. To be honest, I'm somewhat surprised a mechanical translation of assembly to C didn't result in a lot of hard to track down bugs, considering how m

by yoklov 12y ago

Interesting. To be honest, I'm somewhat surprised a mechanical translation of assembly to C didn't result in a lot of hard to track down bugs, considering how much of what's well-defined in assembly being undefined behavior in C.

Aldo_MX 12y ago
GCC displayed more than 1,000 warnings, most of which complain about incompatibility of types. I was actually surprised that it was able to compile. Probably it did.
tedunangst 12y ago
That doesn't really follow. Most of the time, like behavior of integer overflow, the program doesn't really care (as in the machine language version doesn't reflect a specific desire for wrapping behavior, especially for signed values). The naive C version is good enough. And of course, it's always possible to even more carefully disassemble and preserve semantics, though this is usually undesirable because it obscures what's relevant.
- yoklov 12y ago
  Signed wrapping behavior is well-defined in the machine language for every architecture that ever existed (or at least, that I've ever heard of). If the assembly code depends on the wrapping behavior and you translated that to C, you'd get C code that depends on the behavior of signed overflow, which the compiler is free to completely remove, no matter your target. This is a somewhat extreme case, as code that depends on the behavior of signed overflow is rare, but there's a lot of things that are perfectly well specified by the architecture, but that C leaves undefined.
breadbox 12y ago
Actually, most of C's "undefined behavior" is left undefined to permit compilers to define whatever behavior is most natural for the target's assembly. Undefined behavior is an issue when you're trying to write portable code. So it's really not surprising that this worked out in the programmer's favor in this situation.
- yoklov 12y ago
  Nope. You're describing implementation-defined behavior. The compiler is free to assume undefined behavior never happens, and optimize it away if it does. This can be a big problem, whether or not you are trying to write portable code. This series (among many other places on the internet) does a good job explaining the problems http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html http://blog.llvm.org/2011/05/what-every-c-programmer-should-...
  - breadbox 12y ago
    I'm familiar with the difference between the two. It's my experience that what I said is largely true for both, and thus my comments.

by yoklov 12y ago

Aldo_MX 12y ago

GCC displayed more than 1,000 warnings, most of which complain about incompatibility of types. I was actually surprised that it was able to compile. Probably it did.

tedunangst 12y ago

That doesn't really follow. Most of the time, like behavior of integer overflow, the program doesn't really care (as in the machine language version doesn't reflect a specific desire for wrapping behavior, especially for signed values). The naive C version is good enough. And of course, it's always possible to even more carefully disassemble and preserve semantics, though this is usually undesirable because it obscures what's relevant.

yoklov 12y ago
Signed wrapping behavior is well-defined in the machine language for every architecture that ever existed (or at least, that I've ever heard of). If the assembly code depends on the wrapping behavior and you translated that to C, you'd get C code that depends on the behavior of signed overflow, which the compiler is free to completely remove, no matter your target. This is a somewhat extreme case, as code that depends on the behavior of signed overflow is rare, but there's a lot of things that are perfectly well specified by the architecture, but that C leaves undefined.

breadbox 12y ago

Actually, most of C's "undefined behavior" is left undefined to permit compilers to define whatever behavior is most natural for the target's assembly. Undefined behavior is an issue when you're trying to write portable code. So it's really not surprising that this worked out in the programmer's favor in this situation.

yoklov 12y ago
Nope. You're describing implementation-defined behavior. The compiler is free to assume undefined behavior never happens, and optimize it away if it does. This can be a big problem, whether or not you are trying to write portable code. This series (among many other places on the internet) does a good job explaining the problems http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html http://blog.llvm.org/2011/05/what-every-c-programmer-should-...
- breadbox 12y ago
  I'm familiar with the difference between the two. It's my experience that what I said is largely true for both, and thus my comments.