4 ms·

There's an easy way to eliminate unspecified behavior in C or C++: Have a compiler flag to always issue warnings for it and treat those warnings as errors. That

There's an easy way to eliminate unspecified behavior in C or C++: Have a compiler flag to always issue warnings for it and treat those warnings as errors. That doesn't require any language-level changes to implement.

throwawaymaths 2y ago
Complete eradication should never be a goal though. There are extremely reasonable forms of undefined behavior that the compiler can use to optimize your code. It just has to be known that tripping those guardrails is undefined.
jcranmer 2y ago
Considering that unspecified behavior includes whether or not you execute the LHS of a binary operator before the RHS, such a mode would not be very useful. Even assuming you meant undefined behavior instead of unspecified behavior, it's still not a particularly practical prospect, for you basically prohibit any use of pointers (or memory access in general) whatsoever.
bluGill 2y ago
That isn't possible. Does "X / Y" divide by 0? Often the compiler has no way of knowing. Sure code can always check for Y == 0 - but if the programmer has knowledge the compiler doesn't that Y can never be 0 this if statement can needlessly slow down code (CPU branch mispredictions are costly). There are other places where we can prove that code is safe in most conditions but proving the exception never happens is equivalent to proving the halting problem.
- CoastalCoder 2y ago
  Is there a term for predicates that are checked by static analysis when possible, but relegated to runtime checks when not?
  - account42 2y ago
    That's just any runtime check with an optimizing compiler - conditionals that the compiler can prove are always true / always false can get eliminated.
  - UncleMeat 2y ago
    Exhaustive runtime checks for all forms of UB are basically impossible. A data race is UB. Are you going to find a way to insert correct data race detection on all writes? Writing through an invalid pointer alias is UB. How are you going to detect when that happens at runtime? Sanitizers exist and do detect a subset of UB via runtime checks, but there is nothing resembling a system that can detect all UB. That would basically require an entire VM implementing the C-standard with a truly outrageous amount of runtime overhead.
    - torstenvl 2y ago
      The problem is the conflation of at least three different working definitions of "undefined behavior." Strictly speaking, undefined behavior only means that the Standard does not impose a requirement. But what many people mean is that the ramifications are outside the scope of the language or are unpredictable. Writing through an invalid pointer is perfectly definable. The standard could easily specify solely that the write to the memory location indicated in the pointer will be attempted, but that whether the write succeeds and what second- and third-order effects result from such a write are dependent on the environment, including operating system. Boom. Not undefined behavior. But still potentially dangerous behavior with unpredictable results. (In my view, this is in fact what ANSI C requires for this type of "undefined behavior," but many others do not agree.)
      - UncleMeat 2y ago
        > The standard could easily specify solely that the write to the memory location indicated in the pointer will be attempted It could. But now you can't optimize things to store data in registers hardly ever.
      - trealira 2y ago
- uecker 2y ago
  You can do a lot though. And for many of the remaining things, such as all arithmetic UB, one can require run-time traps. The same for bounds checking (which will require some minor language extensions). The only difficult thing is temporal memory safety, but there also several known options what one could do.

throwawaymaths 2y ago

Complete eradication should never be a goal though. There are extremely reasonable forms of undefined behavior that the compiler can use to optimize your code. It just has to be known that tripping those guardrails is undefined.

jcranmer 2y ago

Considering that unspecified behavior includes whether or not you execute the LHS of a binary operator before the RHS, such a mode would not be very useful. Even assuming you meant undefined behavior instead of unspecified behavior, it's still not a particularly practical prospect, for you basically prohibit any use of pointers (or memory access in general) whatsoever.

bluGill 2y ago

That isn't possible. Does "X / Y" divide by 0? Often the compiler has no way of knowing. Sure code can always check for Y == 0 - but if the programmer has knowledge the compiler doesn't that Y can never be 0 this if statement can needlessly slow down code (CPU branch mispredictions are costly). There are other places where we can prove that code is safe in most conditions but proving the exception never happens is equivalent to proving the halting problem.

CoastalCoder 2y ago
Is there a term for predicates that are checked by static analysis when possible, but relegated to runtime checks when not?
- account42 2y ago
  That's just any runtime check with an optimizing compiler - conditionals that the compiler can prove are always true / always false can get eliminated.
- UncleMeat 2y ago
  Exhaustive runtime checks for all forms of UB are basically impossible. A data race is UB. Are you going to find a way to insert correct data race detection on all writes? Writing through an invalid pointer alias is UB. How are you going to detect when that happens at runtime? Sanitizers exist and do detect a subset of UB via runtime checks, but there is nothing resembling a system that can detect all UB. That would basically require an entire VM implementing the C-standard with a truly outrageous amount of runtime overhead.
  - torstenvl 2y ago
    The problem is the conflation of at least three different working definitions of "undefined behavior." Strictly speaking, undefined behavior only means that the Standard does not impose a requirement. But what many people mean is that the ramifications are outside the scope of the language or are unpredictable. Writing through an invalid pointer is perfectly definable. The standard could easily specify solely that the write to the memory location indicated in the pointer will be attempted, but that whether the write succeeds and what second- and third-order effects result from such a write are dependent on the environment, including operating system. Boom. Not undefined behavior. But still potentially dangerous behavior with unpredictable results. (In my view, this is in fact what ANSI C requires for this type of "undefined behavior," but many others do not agree.)
    - UncleMeat 2y ago
      > The standard could easily specify solely that the write to the memory location indicated in the pointer will be attempted It could. But now you can't optimize things to store data in registers hardly ever.
    - trealira 2y ago
uecker 2y ago
You can do a lot though. And for many of the remaining things, such as all arithmetic UB, one can require run-time traps. The same for bounds checking (which will require some minor language extensions). The only difficult thing is temporal memory safety, but there also several known options what one could do.