0

The C standard (AFAIK) uses both terms. I have trouble understanding where the difference between the two is.

If I have any given, syntactically correct C statement, there can be no way that a compiler will not issue some machine instructions. Of course, it could choose to not issue any statement at all, but even that would be "implementation dependant".

A more concrete example: Overflow of integer values. Now we have two types of overflow: arithmetic, and memory-wise. If the overflow of signed integers is UB according to the standard, what does that mean? Could an implementation simply spill an overflowing bit into the adjacent byte to the MSB? (Never seen that, but would it be ok?)

It appears to me that "undefined behaviour" always is implementation dependant. Or, to put it differently, there seems no way a compiler could handle any "undefined behaviour" without introducing "implementation defined" behaviour.

So why even distinguish between the two?

GermanNerd
  • 643
  • 5
  • 12
  • 1
    Read [Undefined, unspecified and implementation-defined behavior](https://stackoverflow.com/questions/2397984/undefined-unspecified-and-implementation-defined-behavior) if you havn't gone through. – Achal Dec 15 '18 at 15:10
  • I have read that, but it does not answer my question. (Or I am too dumb.) I do understand that implementation-defined behaviour (by the standard) will or might impose constrains on what the implementation does, but still "undefined behaviour", IRL, will always result in some implementation behaviour. No? – GermanNerd Dec 15 '18 at 15:16
  • 2
    Your title asks about “implementation defined” behavior, but your question mentions “implementation dependent” behavior (albeit spelled “dependant”). These are different. "Implementation defined" means the implementation **must document** what the behavior is. It is **defined**, so an engineer can know what it is and can design their code to rely on it. In contrast, “implementation dependent” is not a term defined in the C standard. As simple English, it describes something that depends on an implementation. But that does not mean you can know what it will be—it is not documented, so… – Eric Postpischil Dec 15 '18 at 15:35
  • … it may vary from circumstance to circumstance (an overflow in one situation might trap, whereas in another it might wrap), and it might change from compiler version to compiler version. Those variations include different behaviors when your source code changes slightly, when optimization options are changed, and when the circumstances in which the code is operating change. Behavior that is not defined is uncontrolled, even if it depends on the implementation. Implementation-defined behavior is controlled and known. – Eric Postpischil Dec 15 '18 at 15:36
  • UB will make your program do something randomly, you'd be lucky if it crashes. IDB will make your program do something consistently, but you have a read a manual to know what that will be. – Hans Passant Dec 15 '18 at 15:49
  • @HansPassant: “IDB” is ambiguous in a context where OP has used both “implementation defined behavior” and “implementation dependent behavior.” – Eric Postpischil Dec 15 '18 at 20:05
  • @HansPassant: From the Standard's point of view, the only difference between IDB and UB is whether an implementation where characterizing a behavior would be expensive and useless is required to do so anyway. The Standard doesn't say what actions implementations should be expected to process "in a documented fashion characteristic of the environment", but the charter and rationale documents state that implementations that honor the Spirit of C will avoid needlessly impede programmers from "doing what needs to be done". Compilers that don't honor the Spirit of C may do anything, of course. – supercat Dec 17 '18 at 16:15

1 Answers1

4

The main difference is that implementation-defined behavior is defined. That is, for every requirement in the Standard that says "implementation-defined", a C implementation is supposed to come with an explanation of what that behavior is.

For example, here is the GCC documentation on implementation-defined behavior for the C language.

Also, in many cases, "implementation-defined" allows for a decision for one of a number of particular possible behaviors. But "undefined behavior" always allows an implementation to do anything at all, either at compile time or at run time.

Read also Lattner's blog What Every Programmer Should Know About Undefined Behavior.

Basile Starynkevitch
  • 223,805
  • 18
  • 296
  • 547
aschepler
  • 70,891
  • 9
  • 107
  • 161
  • Yes, I've read that as well. It does provide information about the rules or frameworks for "implementation defined" - namely, to document it, but the original question remains: How can "undefined behavior" not be "implementation dependent?" – GermanNerd Dec 15 '18 at 15:21
  • @GermanNerd UB can be "implementation dependent", yet that is still not "implementation-defined behavior". – chux - Reinstate Monica Dec 15 '18 at 16:02
  • The only differences are that (1) conforming implementations are *required* to specify how they process implementation-defined behavior even if doing so would be expensive and useless, while implementers are allowed to use their own judgment as to whether they should define behaviors in cases where the Standard imposes no requirements; (2) compilers who haven't read or do not care about the Spirit of C described in the Standard's charter and rationale documents go out of their way to avoid behaving usefully when not required by the Standard, without regard for whether such actions... – supercat Dec 15 '18 at 16:10
  • ...would interfere with programmers doing what needs to be done--something which directly contradicts the Spirit of C described in the aforementioned documents. – supercat Dec 15 '18 at 16:11