5 ms·

Undefined behaviour is in fact runtime behaviour. To catch it, you need to run the program (or use static analysis tools). Calling that a weakness is like comp

Undefined behaviour is in fact runtime behaviour. To catch it, you need to run the program (or use static analysis tools). Calling that a weakness is like complaining that the compiler can't know all inputs to a running program in advance.

clarry 7y ago
Undefined behavior is not strictly limited to runtime. For example, defining a function called toilet is undefined behavior in C, but function names are hardly a runtime construct (except as far as dynamic linking is concerned).
- jstimpfle 7y ago
  Why is defining a functon called toilet UB? (it is not even B, in my opinion)
  - clarry 7y ago
    Reserved identifier. > If the program declares or defines an identifier in a context in which it is reserved (other than as allowed by 7.1.4), or defines a reserved identifier as a macro name, the behavior is undefined.
    - jstimpfle 7y ago
      My best guess is that compilers simply cannot be expected to catch that problem statically. Think about the way the header files that come with standard library interact with the program source code, for example. It's hard to know where exactly the use of a reserved identifier originated from, and which parts are considered "the implementation" (which is allowed to use reserved identifiers). Messing with system headers might still result in a compilable translation unit, with unpredictable behaviour. Likewise, defining symbols with reserved identifiers might result in a linkable program (statically and/or dynamically), but again if you mess with the implementation the runtime behaviour is unpredictable.
      - clarry 7y ago
        I agree that there are cases where a naive implementation would have a hard time distinguishing implementation from program (and even in case of a non-naive implementation, it can be a line drawn in water), so this sort of thing might be warranted. Though that was just one example among many, and there are many instances of undefined behavior that are very much compile-time. For example: > The same identifier has both internal and external linkage in the same translation unit > Two declarations of the same object or function specify types that are not compatible > An attempt is made to use the value of a void expression, or an implicit or explicit conversion (except to void) is applied to a void expression > An unmatched ' or " character is encountered on a logical source line during tokenization > Two identifiers differ only in nonsignificant characters > The identifier __func__ is explicitly declared > The characters ', \, ", //, or /* occur in the sequence between the < and > delimiters, or the characters ', \, //, or /* occur in the sequence between the " delimiters, in a header name preprocessing token > An expression that is required to be an integer constant expression does not have an integer type You get the idea. That's just what I gathered from quickly skimming the first screenful (out of about 4) in the list of UB in N1256.
        jstimpfle 7y ago
        Yes. These, to me, seem to codify limitations of ancient compilers. Modern compilers will catch these problems at compile time.
woah 7y ago
Seems like an odd standard of what’s allowed to be called a weakness. If something in a language makes writing well-functioning code harder for a lot of people, then they are probably justified in calling it a weakness.
- jstimpfle 7y ago
  The horror stories about compilers optimizing away code based on statically detected UB are frightening, and largely the compiler vendors seem to be to blame. But there's also a good amount of FUD in the play. Personally I'm not sure I've ever encountered any problems with UB. Sure, I've had my share of NULL dereferences, but in practice they manifest as segfaults, which are akin to exceptions in other languages. And while the list of UBs in C can still be considered a weakness, the fact that compilers usually don't issue a warning is not, because UB is a runtime thing, so compilers cannot do anything about it (in general, and typically). That is something that seems to be not well understood. And it was the point I was making.

clarry 7y ago

Undefined behavior is not strictly limited to runtime. For example, defining a function called toilet is undefined behavior in C, but function names are hardly a runtime construct (except as far as dynamic linking is concerned).

jstimpfle 7y ago
Why is defining a functon called toilet UB? (it is not even B, in my opinion)
- clarry 7y ago
  Reserved identifier. > If the program declares or defines an identifier in a context in which it is reserved (other than as allowed by 7.1.4), or defines a reserved identifier as a macro name, the behavior is undefined.
  - jstimpfle 7y ago
    My best guess is that compilers simply cannot be expected to catch that problem statically. Think about the way the header files that come with standard library interact with the program source code, for example. It's hard to know where exactly the use of a reserved identifier originated from, and which parts are considered "the implementation" (which is allowed to use reserved identifiers). Messing with system headers might still result in a compilable translation unit, with unpredictable behaviour. Likewise, defining symbols with reserved identifiers might result in a linkable program (statically and/or dynamically), but again if you mess with the implementation the runtime behaviour is unpredictable.
    - clarry 7y ago
      I agree that there are cases where a naive implementation would have a hard time distinguishing implementation from program (and even in case of a non-naive implementation, it can be a line drawn in water), so this sort of thing might be warranted. Though that was just one example among many, and there are many instances of undefined behavior that are very much compile-time. For example: > The same identifier has both internal and external linkage in the same translation unit > Two declarations of the same object or function specify types that are not compatible > An attempt is made to use the value of a void expression, or an implicit or explicit conversion (except to void) is applied to a void expression > An unmatched ' or " character is encountered on a logical source line during tokenization > Two identifiers differ only in nonsignificant characters > The identifier __func__ is explicitly declared > The characters ', \, ", //, or /* occur in the sequence between the < and > delimiters, or the characters ', \, //, or /* occur in the sequence between the " delimiters, in a header name preprocessing token > An expression that is required to be an integer constant expression does not have an integer type You get the idea. That's just what I gathered from quickly skimming the first screenful (out of about 4) in the list of UB in N1256.
      - jstimpfle 7y ago
        Yes. These, to me, seem to codify limitations of ancient compilers. Modern compilers will catch these problems at compile time.

woah 7y ago

Seems like an odd standard of what’s allowed to be called a weakness. If something in a language makes writing well-functioning code harder for a lot of people, then they are probably justified in calling it a weakness.

jstimpfle 7y ago
The horror stories about compilers optimizing away code based on statically detected UB are frightening, and largely the compiler vendors seem to be to blame. But there's also a good amount of FUD in the play. Personally I'm not sure I've ever encountered any problems with UB. Sure, I've had my share of NULL dereferences, but in practice they manifest as segfaults, which are akin to exceptions in other languages. And while the list of UBs in C can still be considered a weakness, the fact that compilers usually don't issue a warning is not, because UB is a runtime thing, so compilers cannot do anything about it (in general, and typically). That is something that seems to be not well understood. And it was the point I was making.