5

Wikipedia has pages about undefined and unspecified behavior and links to them are plentifully used in comments and answers here, in SO.

Each one begins with a note to not be confused with other one but except one no very clear sentence they didn't point at the difference between them.

One of them gives an example (comparing addresses of 2 variables: &a < &b) with the comment that this will results in unspecified behavior in C++, undefined in C.

Is it possible to pinpoint the substantial difference between undefined and unspecified behavior in a clear, understandable manner?

MarianD
  • 13,096
  • 12
  • 42
  • 54

2 Answers2

16

In short:

  • Undefined behaviour: this is not okay to do
  • Unspecified behaviour: this is okay to do, but the result could be anything*
  • Implementation-defined behaviour: this is okay to do, the result could be anything* but the compiler manual should tell you

Or, in quotes from the C++ standard (N4659 section 3, Terms and Definitions):

3.28 Undefined behavior: behavior for which this International Standard imposes no requirements

3.29 Unspecified behavior: behavior, for a well-formed program construct and correct data, that depends on the implementation

3.12 Implementation-defined behavior: behavior, for a well-formed program construct and correct data, that depends on the implementation and that each implementation documents

EDIT: *As pointed out by M.M in the comments, saying that the result of unspecified behaviour could be anything is not quite right. In fact as the standard itself points out, in a note for paragraph 3.29

The range of possible behaviors is usually delineated by this International Standard.

So in practise you have some idea of what the possible results are, but what exactly will happen depends on your compiler/compiler flags/platform/etc.

Community
  • 1
  • 1
Tristan Brindle
  • 16,281
  • 4
  • 39
  • 82
  • Nice answer, up voting. But still is something unclear: 3.28 - no requirements. Does it mean that for 3.29 and 3.12 there are some requirements? – MarianD May 26 '17 at 00:56
  • May I ask you to closely specify which C++ standard you used (and - if it is possible - to provide the link to it)? – MarianD May 26 '17 at 01:04
  • @MarianD Those quotes are taken from the latest C++17 draft standard, (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/n4659.pdf), though I don't think they're any different from earlier versions of C++ – Tristan Brindle May 26 '17 at 01:19
  • @MarianD In practise, in cases of unspecified behaviour the standard does actually give indications of what behaviours are possible, and it's up to the implementation to pick one (so perhaps "partially specified" might be a better term, but "unspecified" has stuck now). – Tristan Brindle May 26 '17 at 01:22
  • Thanks! Perhaps you may include it in your answer. – MarianD May 26 '17 at 01:23
  • 1
    I'd disagree with this characterization of unspecified behaviour; the result could not be *anything*. There are a finite number of possible results that can be determined from the other rules in the standard; and the result could be any one of that set, but not anything else. – M.M May 26 '17 at 02:22
  • @M.M You're right, I was trying too hard for a pithy summary :). I've added a note about possible behaviours, feel free to edit the answer further if you think it needs polishing. – Tristan Brindle May 26 '17 at 02:39
0

Unspecified and its example ( &a < &b ) seems to say the compiler writer does not have to make a commitment to where it stores variables on a stack, and the result could change if nearby items were added or deleted (without changing the order of declaration of a and b).

Implementation specific is items such as a % b where the result is at the implementation's discretion (usually based on the hardware), as to what happens when a is negative.

Here it is important to describe what will happen, but would impact performance if the standard committed to a specific behavior.

Undefined behavior is describing the point your program becomes ill-formed - it may work on a particular platform, but not for any good reasons.

mksteve
  • 12,614
  • 3
  • 28
  • 50