{{short description|Differing behavior by identically-coded programs when compiled}} {{Distinguish|Undefined behavior}}
In computer programming, '''unspecified behavior''' is behavior that may vary on different implementations of a programming language.{{clarify|date=September 2012}}<!--very vague term here; is it behavior on the part of the compiler, on the part of the hardware running the program, or what?--> A program can be said to contain unspecified behavior when its source code may produce an executable that exhibits different behavior when compiled on a different compiler, or on the same compiler with different settings, or indeed in different parts of the same executable. While the respective language standards or specifications may impose a range of possible behaviors, the exact behavior depends on the implementation and may not be completely determined upon examination of the program's source code.<ref name="pdtr">ISO/IEC (2009-05-29). ''ISO/IEC PDTR 24772.2: Guidance to Avoiding Vulnerabilities in Programming Languages through Language Selection and Use''</ref> Unspecified behavior will often not manifest itself in the resulting program's external behavior, but it may sometimes lead to differing outputs or results, potentially causing portability problems.
==Definition== To enable compilers to produce optimal code for their respective target platforms, programming language standards do not always impose a certain specific behavior for a given source code construct.<ref name="ddj_becker">{{cite magazine|url=http://www.ddj.com/cpp/187203727?pgno=2|title=Living By the Rules|last=Becker|first=Pete|date=2006-05-16|magazine=Dr. Dobb's Journal|access-date=26 November 2009}}</ref> Failing to explicitly define the exact behavior of every possible program is not considered an error or weakness in the language specification, and doing so would be infeasible.<ref name="pdtr"/> In the C and C++ languages, such non-portable constructs are generally grouped into three categories: Implementation-defined, unspecified, and undefined behavior.<ref name="industrialcpp">{{cite book |last1=Henricson |first1=Mats |last2=Nyquist |first2=Erik |title=Industrial Strength C++ |publisher=Prentice Hall |year=1997 |isbn=0-13-120965-5 |url-access=registration |url=https://archive.org/details/industrialstreng0000henr }} </ref>
The exact definition of unspecified behavior varies. In C++, it is defined as "behavior, for a well-formed program construct and correct data, that depends on the implementation."<ref name="C++03 1.3.13">ISO/IEC (2003). ''ISO/IEC 14882:2003(E): Programming Languages - C++ §1.3.13 unspecified behavior [defns.unspecified]''</ref> The C++ Standard also notes that the range of possible behaviors is usually provided.<ref name="C++03 1.3.13"/> Unlike implementation-defined behavior, there is no requirement for the implementation to document its behavior.<ref name="C++03 1.3.13"/> Similarly, the C Standard defines it as behavior for which the standard "provides two or more possibilities and imposes no further requirements on which is chosen in any instance".<ref name="c99_usb">ISO/IEC (1999). ''ISO/IEC 9899:1999(E): Programming Languages - C §3.4.4 para 1''</ref> Unspecified behavior is different from undefined behavior. The latter is typically a result of an erroneous program construct or data, and no requirements are placed on the translation or execution of such constructs.<ref name="C++03 1.3.12">ISO/IEC (2003). ''ISO/IEC 14882:2003(E): Programming Languages - C++ §1.3.12 undefined behavior [defns.undefined]''</ref>
==Implementation-defined behavior== C and C++ distinguish ''implementation-defined behavior'' from unspecified behavior. For implementation-defined behavior, the implementation must choose a particular behavior and document it. An example in C/C++ is the size of integer data types. The choice of behavior must be consistent with the documented behavior within a given execution of the program.
==Examples== ===Order of evaluation of subexpressions=== Many programming languages do not specify the order of evaluation of the sub-expressions of a complete expression. This non-determinism can allow optimal implementations for specific platforms e.g. to utilise parallelism. If one or more of the sub-expressions has side effects, then the result of evaluating the full-expression may be different depending on the order of evaluation of the sub-expressions.<ref name="pdtr"/> For example, given <syntaxhighlight lang="c">a = f(b) + g(b);</syntaxhighlight>, where <code>f</code> and <code>g</code> both modify <code>b</code>, the result stored in <code>a</code> may be different depending on whether <code>f(b)</code> or <code>g(b)</code> is evaluated first.<ref name="pdtr"/> In the C and C++ languages, this also applies to function arguments. Example:<ref name="ddj_becker"/> <syntaxhighlight lang="cpp"> #include <iostream> int f() { std::cout << "In f\n"; return 3; }
int g() { std::cout << "In g\n"; return 4; }
int sum(int i, int j) { return i + j; }
int main() { return sum(f(), g()); } </syntaxhighlight> The resulting program will write its two lines of output in an unspecified order.<ref name="ddj_becker"/> In some other languages, such as Java, the order of evaluation of operands and function arguments is explicitly defined.<ref name="jls">James Gosling, Bill Joy, Guy Steele, and Gilad Bracha (2005). ''The Java Language Specification'', Third Edition. Addison-Wesley. {{ISBN|0-321-24678-0}}</ref>
==See also== *Software portability *Undefined behavior
==References== {{reflist}}
Category:Articles with example C code Category:Articles with example C++ code Category:Computer programming Category:Programming language implementation