6 ms·

At some point some popular compiler is going to make a subtle but important change to some undefined behavior that's not going to be immediately obvious as to i

At some point some popular compiler is going to make a subtle but important change to some undefined behavior that's not going to be immediately obvious as to it's repercussions, and the fallout will be massive. Wait until you realize that the length of a byte in C is not clearly defined. Someday a processor will come along where a byte is 6 bits, and the fallout will be massive. (Really, it's happened before). No, actually that processor would not become popular because on one would use it. The reality is unless you are using a formally-defined language like ML, you are relying on undefined behavior in your language.

tatterdemalion 11y ago
Its far more likely for a major compiler to exploit more undefined behavior for optimizations than for a processor with a bizarre sized byte to become popular. The major compilers already do this. > The reality is unless you are using a formally-defined language like ML, you are relying on undefined behavior in your language. This is not true, not using the definition of "undefined behavior" provided in the C standard.
_kst_ 11y ago
The number of bits in a byte is specified by the CHAR_BIT macro, which is required to be at least 8. It's commonly larger than 8 on C compilers for some DSPs, but almost universally 8 for hosted implementations. POSIX specifically requires it to be exactly 8.
jerf 11y ago
Did you see the short-lived attempt to create "friendly C" a few months ago? [1] There's languages that have a few undefined corners, and then there's C. A sufficiently large difference in quantity becomes a difference in quality. C is qualitatively worse than most modern languages with its undefined behavior. (Granted, some modern languages escape by having the one implementation, which is then the definition. But still, that's less undefined than C.) [1]: http://blog.regehr.org/archives/1287 http://blog.regehr.org/archives/1287
- Dylan16807 11y ago
  It was too ambitious. Some of those examples, like shifting by 32, are about trying to remove even unspecified behavior. If you could reduce most cases of undefined behavior down to "what some real machine would do", it would be an enormous help, and wouldn't be anywhere near as hard. For example you could say that division by zero will either give a result or trap, but that it can't do anything else, and the code path cannot be ignored. Or that an uninitialized variable is equivalent to initializing it with a semi-random number. Even if an out of bounds array access will cause untold chaos, you can at least specify that it will cause that chaos at X bytes past the base of the array. Merely creating an invalid pointer would be, on architectures where it doesn't trap, 100% harmless. And for crying out loud, is forgetting to terminate a string literal with a " still undefined? There are so many bits of undefined behavior that are easy to remove.
  - pcwalton 11y ago
    > Or that an uninitialized variable is equivalent to initializing it with a semi-random number. This proposal destroys lots of dead code elimination optimizations that are very important in code post inlining (for example, in the STL).
    - Dylan16807 11y ago
      Can you explain why? What if we relax it to say that copying from one uninitialized variable to another can be omitted?
      - pcwalton 11y ago
        Because uninitialized variables are allowed to change values arbitrarily over their (nonexistent) "live range". Your proposal would force them into having a real live range, with a stable value. See this section for an example, which shows examples of the kinds of optimizations this opens up: http://llvm.org/docs/LangRef.html#undefined-values http://llvm.org/docs/LangRef.html#undefined-values There's also the issue that having a stable value forces the register allocator to keep a live range for the undefined variable, which can cause unnecessary spills or remat in other places. Especially on 32-bit x86, this can be a problem.
dalke 11y ago
> The reality is unless you are using a formally-defined language like ML, you are relying on undefined behavior in your language. The CompCert C verified compiler is a verified compiler which supports "almost all of the ISO C90 / ANSI C language" - http://compcert.inria.fr/ http://compcert.inria.fr/ . It isn't C. It is a formally-defined language that is very similar to C. It is otherwise nothing like ML.

tatterdemalion 11y ago

Its far more likely for a major compiler to exploit more undefined behavior for optimizations than for a processor with a bizarre sized byte to become popular. The major compilers already do this. > The reality is unless you are using a formally-defined language like ML, you are relying on undefined behavior in your language. This is not true, not using the definition of "undefined behavior" provided in the C standard.

_kst_ 11y ago

The number of bits in a byte is specified by the CHAR_BIT macro, which is required to be at least 8. It's commonly larger than 8 on C compilers for some DSPs, but almost universally 8 for hosted implementations. POSIX specifically requires it to be exactly 8.

jerf 11y ago

Did you see the short-lived attempt to create "friendly C" a few months ago? [1] There's languages that have a few undefined corners, and then there's C. A sufficiently large difference in quantity becomes a difference in quality. C is qualitatively worse than most modern languages with its undefined behavior. (Granted, some modern languages escape by having the one implementation, which is then the definition. But still, that's less undefined than C.) [1]: http://blog.regehr.org/archives/1287 http://blog.regehr.org/archives/1287

Dylan16807 11y ago
It was too ambitious. Some of those examples, like shifting by 32, are about trying to remove even unspecified behavior. If you could reduce most cases of undefined behavior down to "what some real machine would do", it would be an enormous help, and wouldn't be anywhere near as hard. For example you could say that division by zero will either give a result or trap, but that it can't do anything else, and the code path cannot be ignored. Or that an uninitialized variable is equivalent to initializing it with a semi-random number. Even if an out of bounds array access will cause untold chaos, you can at least specify that it will cause that chaos at X bytes past the base of the array. Merely creating an invalid pointer would be, on architectures where it doesn't trap, 100% harmless. And for crying out loud, is forgetting to terminate a string literal with a " still undefined? There are so many bits of undefined behavior that are easy to remove.
- pcwalton 11y ago
  > Or that an uninitialized variable is equivalent to initializing it with a semi-random number. This proposal destroys lots of dead code elimination optimizations that are very important in code post inlining (for example, in the STL).
  - Dylan16807 11y ago
    Can you explain why? What if we relax it to say that copying from one uninitialized variable to another can be omitted?
    - pcwalton 11y ago
      Because uninitialized variables are allowed to change values arbitrarily over their (nonexistent) "live range". Your proposal would force them into having a real live range, with a stable value. See this section for an example, which shows examples of the kinds of optimizations this opens up: http://llvm.org/docs/LangRef.html#undefined-values http://llvm.org/docs/LangRef.html#undefined-values There's also the issue that having a stable value forces the register allocator to keep a live range for the undefined variable, which can cause unnecessary spills or remat in other places. Especially on 32-bit x86, this can be a problem.

dalke 11y ago

> The reality is unless you are using a formally-defined language like ML, you are relying on undefined behavior in your language. The CompCert C verified compiler is a verified compiler which supports "almost all of the ISO C90 / ANSI C language" - http://compcert.inria.fr/ http://compcert.inria.fr/ . It isn't C. It is a formally-defined language that is very similar to C. It is otherwise nothing like ML.