Details of a system that are not specified by the requirements of the system (but which might be by an implementation of the system). Unlike
UndefinedBehavior (which is always a
BadThing), unspecified behavior generally represents a degree of freedom on the part of an implementor; such as choice of data structure for an associative array. (
RedBlackTree?
HashTable?
LinkedList?).
Portable programs should not depend on
UnspecifiedBehavior. Programs which are not intended to be portable might benefit from relying on
UnspecifiedBehavior, though others may disagree. (
Personally, I think that an informed decision to lose portability should be made by stakeholders on a project before depending on unspecified behavior. There are times when it is appropriate.)
The C99 standard defines
UnspecifiedBehavior
3.4.4
#1
unspecified behavior: behavior where this International Standard provides two or more possibilities and
imposes no further requirements on which is chosen in any instance
#2 EXAMPLE An example of unspecified behavior is the order in which the arguments to a function are
evaluated.
[
ImplementationDefined behavior is:] Unspecified behavior where each implementation documents how the choice is made.
See UndefinedBehavior for problems with how these terms are defined in C99.
Wait a sec - there is an official standard
UnspecifiedBehavior?
We demand guaranteed, rigidly defined areas of uncertainty and doubt! -- Vroomfondel, HitchhikersGuideToTheGalaxy
See also
ImplementationDefined,
UndefinedBehavior.