Namespaces
Variants
Views
Actions

Undefined behavior

From cppreference.com
< cpp‎ | language
 
 
C++ language
General topics
Flow control
Conditional execution statements
if
Iteration statements (loops)
for
range-for (C++11)
Jump statements
Functions
Function declaration
Lambda function expression
inline specifier
Dynamic exception specifications (until C++17*)
noexcept specifier (C++11)
Exceptions
Namespaces
Types
Specifiers
decltype (C++11)
auto (C++11)
alignas (C++11)
Storage duration specifiers
Initialization
Expressions
Alternative representations
Literals
Boolean - Integer - Floating-point
Character - String - nullptr (C++11)
User-defined (C++11)
Utilities
Attributes (C++11)
Types
typedef declaration
Type alias declaration (C++11)
Casts
Implicit conversions - Explicit conversions
static_cast - dynamic_cast
const_cast - reinterpret_cast
Memory allocation
Classes
Class-specific function properties
explicit (C++11)
static
Special member functions
Templates
Miscellaneous
 
 

Renders the entire program meaningless if certain rules of the language are violated.

Contents

[edit] Explanation

The C++ standard precisely defines the observable behavior of every C++ program that does not fall into one of the following classes:

  • ill-formed - the program has syntax errors or diagnosable semantic errors. A conforming C++ compiler is required to issue a diagnostic, even if it defines a language extension that assigns meaning to such code (such as with variable-length arrays). The text of the standard uses shall, shall not, and ill-formed to indicate these requirements.
  • ill-formed, no diagnostic required - the program has semantic errors which may not be diagnosable in general case (e.g. violations of the ODR or other errors that are only detectable at link time). The behavior is undefined if such program is executed.
  • implementation-defined behavior - the behavior of the program varies between implementations, and the conforming implementation must document the effects of each behavior. For example, the type of std::size_t or the number of bits in a byte, or the text of std::bad_alloc::what. A subset of implementation-defined behavior is locale-specific behavior, which depends on the implementation-supplied locale.
  • unspecified behavior - the behavior of the program varies between implementations, and the conforming implementation is not required to document the effects of each behavior. For example, order of evaluation, whether identical string literals are distinct, the amount of array allocation overhead, etc. Each unspecified behavior results in one of a set of valid results.
  • undefined behavior - there are no restrictions on the behavior of the program. Some examples of undefined behavior are data races, memory accesses outside of array bounds, signed integer overflow, null pointer dereference, more than one modifications of the same scalar in an expression without any intermediate sequence point(until C++11)that is unsequenced(since C++11), access to an object through a pointer of a different type, etc. Compilers are not required to diagnose undefined behavior (although many simple situations are diagnosed), and the compiled program is not required to do anything meaningful.

[edit] UB and optimization

Because correct C++ programs are free of undefined behavior, compilers may produce unexpected results when a program that actually has UB is compiled with optimization enabled:

For example,

[edit] Signed overflow

int foo(int x)
{
    return x + 1 > x; // either true or UB due to signed overflow
}

may be compiled as (demo)

foo(int):
        mov     eax, 1
        ret

[edit] Access out of bounds

int table[4] = {};
bool exists_in_table(int v)
{
    // return true in one of the first 4 iterations or UB due to out-of-bounds access
    for (int i = 0; i <= 4; i++)
        if (table[i] == v)
            return true;
    return false;
}

May be compiled as (demo)

exists_in_table(int):
        mov     eax, 1
        ret

[edit] Uninitialized scalar

std::size_t f(int x)
{
    std::size_t a;
    if (x) // either x nonzero or UB
        a = 42;
    return a;
}

May be compiled as (demo)

f(int):
        mov     eax, 42
        ret

The output shown was observed on an older version of gcc

#include <cstdio>
 
int main()
{
    bool p; // uninitialized local variable
    if (p)  // UB access to uninitialized scalar
        std::puts("p is true");
    if (!p) // UB access to uninitialized scalar
        std::puts("p is false");
}

Possible output:

p is true
p is false

[edit] Invalid scalar

int f()
{
    bool b = true;
    unsigned char* p = reinterpret_cast<unsigned char*>(&b);
    *p = 10;
    // reading from b is now UB
    return b == 0;
}

May be compiled as (demo)

f():
        mov     eax, 11
        ret

[edit] Null pointer dereference

It is arguable whether merely dereferencing a null pointer is undefined behavior, see CWG issue 2823. The examples demonstrate reading from the result of such deferencing.

int foo(int* p)
{
    int x = *p;
    if (!p)
        return x; // Either UB above or this branch is never taken
    else
        return 0;
}
int bar()
{
    int* p = nullptr;
    return *p; // Unconditional UB
}

may be compiled as (demo)

foo(int*):
        xor     eax, eax
        ret
bar():
        ret

[edit] Access to pointer passed to std::realloc

Choose clang to observe the output shown

#include <cstdlib>
#include <iostream>
 
int main()
{
    int *p = (int*)std::malloc(sizeof(int));
    int *q = (int*)std::realloc(p, sizeof(int));
    *p = 1; // UB access to a pointer that was passed to realloc
    *q = 2;
    if (p == q) // UB access to a pointer that was passed to realloc
        std::cout << *p << *q << '\n';
}

Possible output:

12

[edit] Infinite loop without side-effects

Choose clang or the latest gcc to observe the output shown.

#include <iostream>
 
bool fermat()
{
    const int max_value = 1000;
 
    // Endless loop with no side effects is UB
    for (int a = 1, b = 1, c = 1; true; )
    {
        if (((a * a * a) == ((b * b * b) + (c * c * c))))
            return true; // disproved :()
        a++;
        if (a > max_value)
        {
            a = 1;
            b++;
        }
        if (b > max_value)
        {
            b = 1;
            c++;
        }
        if (c > max_value)
            c = 1;
    }
 
    return false; // not disproved
}
 
int main()
{
    std::cout << "Fermat's Last Theorem ";
    fermat()
        ? std::cout << "has been disproved!\n"
        : std::cout << "has not been disproved.\n";
}

Possible output:

Fermat's Last Theorem has been disproved!

[edit] Ill-formed with diagnostic message

Note that compilers are permitted to extend the language in ways that give meaning to ill-formed programs. The only thing C++ standard requires in such cases is a diagnostic message (compiler warning), unless the program was "ill-formed no diagnostic required".

For example, unless language extensions are disabled via --pedantic-errors, GCC will compile the following example with only a warning even though it appears in the C++ standard as an example of an "error" (see also GCC Bugzilla #55783)

#include <iostream>
 
// Example tweak, do not use constant
double a{1.0};
 
// Standard C++23, 9.4.5 List-initialization [dcl.init.list]
// [Example 6:
struct S
{
    // no initializer-list constructors
    S(int, double, double); // #1
    S();                    // #2
    // ...
};
 
S s1 = {1, 2, 3.0}; // OK, invoke #1
S s2{a, 2, 3}; // error: narrowing
S s3{}; // OK, invoke #2
// — end example]
 
S::S(int, double, double) {}
S::S() {}
 
int main()
{
    std::cout << "All checks have passed.\n";
}

Possible output:

main.cpp:17:6: error: type 'double' cannot be narrowed to 'int' in initializer list ⤶
[-Wc++11-narrowing]
S s2{a, 2, 3}; // error: narrowing
     ^
main.cpp:17:6: note: insert an explicit cast to silence this issue
S s2{a, 2, 3}; // error: narrowing
     ^
     static_cast<int>( )
1 error generated.

[edit] References

Extended content
  • C++23 standard (ISO/IEC 14882:2023):
  • 3.25 ill-formed program [defns.ill.formed]
  • 3.26 implementation-defined behavior [defns.impl.defined]
  • 3.66 unspecified behavior [defns.unspecified]
  • 3.68 well-formed program [defns.well.formed]
  • C++20 standard (ISO/IEC 14882:2020):
  • TBD ill-formed program [defns.ill.formed]
  • TBD implementation-defined behavior [defns.impl.defined]
  • TBD unspecified behavior [defns.unspecified]
  • TBD well-formed program [defns.well.formed]
  • C++17 standard (ISO/IEC 14882:2017):
  • TBD ill-formed program [defns.ill.formed]
  • TBD implementation-defined behavior [defns.impl.defined]
  • TBD unspecified behavior [defns.unspecified]
  • TBD well-formed program [defns.well.formed]
  • C++14 standard (ISO/IEC 14882:2014):
  • TBD ill-formed program [defns.ill.formed]
  • TBD implementation-defined behavior [defns.impl.defined]
  • TBD unspecified behavior [defns.unspecified]
  • TBD well-formed program [defns.well.formed]
  • C++11 standard (ISO/IEC 14882:2011):
  • TBD ill-formed program [defns.ill.formed]
  • TBD implementation-defined behavior [defns.impl.defined]
  • TBD unspecified behavior [defns.unspecified]
  • TBD well-formed program [defns.well.formed]
  • C++98 standard (ISO/IEC 14882:1998):
  • TBD ill-formed program [defns.ill.formed]
  • TBD implementation-defined behavior [defns.impl.defined]
  • TBD unspecified behavior [defns.unspecified]
  • TBD well-formed program [defns.well.formed]

[edit] See also

C documentation for Undefined behavior

[edit] External links

1.  The LLVM Project Blog: What Every C Programmer Should Know About Undefined Behavior #1/3
2.  The LLVM Project Blog: What Every C Programmer Should Know About Undefined Behavior #2/3
3.  The LLVM Project Blog: What Every C Programmer Should Know About Undefined Behavior #3/3
4.  Undefined behavior can result in time travel (among other things, but time travel is the funkiest)
5.  Understanding Integer Overflow in C/C++
6.  Fun with NULL pointers, part 1 (local exploit in Linux 2.6.30 caused by UB due to null pointer dereference)
7.  Undefined Behavior and Fermat’s Last Theorem.