3 ms·

I think the idea is that any reliance on undefined behavior would blow up in your face and immediately cause a bugs, rather than working correctly with some com

• kazinator 11y ago
  The problem is that undefined behaviors are used for valid extensions. "Undefined behavior" doesn't mean "error". For instance including a platform header like #include <fortran.h> is undefined behavior. ISO C has some requirements there: if the header is found, then the directive is replaced with the preprocessing tokens from reading that header (and so if there are syntax errors there, they have to be diagnosed, and so on). But ISO C specifies no requirements as to what <fortran.h> contains, or whether it exists. On one implementation, it might cause the rest of the translation unit to be treated as a Fortran program. On an other implementation, it might bring in some declarations related to a Fortran interoperability. On yet another, translation might stop with "header not found: fortran.h". UB is simply "behavior upon use of a nonportable or erroneous construct, of erroneous data, or of indeterminately-valued objects for which [ISO C] imposes no requirements". Nonportable is not necessarily erroneous!
  • pmjordan 11y ago
    There is a difference, in the standard, between undefined and implementation-defined (unspecified) behaviour though.
    • kazinator 11y ago
      There is also a difference between "implementation-defined" and "unspecified". Look it up! The former is similar to the latter, only it must be documented. Unspecified behaviors imply some choice from among alternatives which need not be documented. (Like the order in which the argument expressions of a function are evaluated.)