Unspecified Behavior

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