-7

Just how undefined is undefined behavior? I've read claims that various C standards allow all behavior after the first undefined behavior to be effectively arbitrary. You'll see people say four basic levels of undefinedness for a statement like i = i++;:

  1. "i could be either i or i+1 after the statement."
  2. "i could hold any value after the statement."
  3. Anything could happen to any values, or execution could halt entirely, but compiling i = i++; with specific side effects like system("rm -rf /"); is non-conforming.
  4. Absolutely anything could happen, including system("rm -rf /");! The trigger-happy filesystem destroying compiler I describe is 100% conforming.

I believe that the answer is not 1, but which is it (if any of these)? If the answer depends on which specific C standard one references then a vector of answers would be nice.

Edit: The linked possible duplicate isn't really the same question (it's more asking if the possibility of undefined behavior along one code path results in undefinedness regardless of the code path), but the answer to this question directly states that the answer is 4 -- namely, undefined really does mean that the standard places no constraints whatsoever on the behavior. I'm not sure why all the downvotes...

Second edit: The second linked question also isn't a duplicate. It's simply asking about why a given statement is undefined (the answer of course being the subtleties of sequence points). Again, this question's top answer directly speaks to my question, albeit with no authoritative citation (unlike the accepted answer).

Community
  • 1
  • 1
FakeName123
  • 137
  • 5
  • https://en.wikipedia.org/wiki/Undefined_behavior - " the implementation will be considered correct whatever it does in such cases" – Suma May 29 '16 at 18:10
  • Quoting wikipedia, undefined behavior (UB) is the result of executing computer code that does not have a prescribed behavior by the language specification the code adheres to, for the current state of the program (e.g. memory). By definition, it does **not** mean that anything could happen. It just means that the behavior is not defined in the language standard. Compilers adhering to the language specification may choose to implement it in any way they like. – Mukul Gupta May 29 '16 at 18:11
  • 2
    Nice question which does not belong [here](http://stackoverflow.com/help/asking), AFAIK. – user3078414 May 29 '16 at 18:11
  • This is why I hate cute analogies. People completely miss the forest for the trees. – uh oh somebody needs a pupper May 29 '16 at 18:12
  • 3
    Possible duplicate of [How undefined is undefined behavior?](http://stackoverflow.com/questions/7961067/how-undefined-is-undefined-behavior) – uh oh somebody needs a pupper May 29 '16 at 18:13
  • Possible duplicate of [Why are these constructs (using ++) undefined behavior?](http://stackoverflow.com/questions/949433/why-are-these-constructs-using-undefined-behavior) – too honest for this site May 29 '16 at 18:38

1 Answers1

0

Officially, "undefined behavior" is defined as:

behavior, upon use of a nonportable or erroneous program construct or of erroneous data, for which this International Standard imposes no requirements

2 NOTE Possible undefined behavior ranges from ignoring the situation completely with unpredictable results, to behaving during translation or program execution in a documented manner characteristic of the environment (with or without the issuance of a diagnostic message), to terminating a translation or execution (with the issuance of a diagnostic message).

That's all it means. There is no secret meaning, ambiguity or "holy truth" behind this paragraph.

Trying to reason about undefined behavior is a pointless exercise, both for the programmer and the compiler. For the programmer, you're wasting time worrying about non-portable and erroneous behavior when you could be fixing bugs and writing code. For the compiler, it is impossible to catch every instance of undefined behavior: that's equivalent to the halting problem. That's why it's undefined behavior in the first place. Because it would be unreasonably restrictive and no doubt make the jobs of compiler writers harder or impossible if it wasn't.

Here's a simple and technically non-analogous example. In Brainfuck, there is nothing in the spec that says what to do about unbalanced brackets. It would simplify the implementation to basically not check for balanced brackets (less code and logic) at the cost of the program appearing to work correctly, not working correctly, or seg faulting (i.e, doing an operation on an empty container).

C is a much more complex language. If there was no "undefined behavior" in C, the specification would probably be 1300 pages long.

John Cena
  • 147
  • 1
  • 6