What are all the common undefined behaviours that a C++ programmer should know about? [closed]

Answer 1

My favourite is "Infinite recursion in the instantiation of templates" because I believe it's the only one where the undefined behaviour occurs at compile time.

Answer 2

Pointer

• Dereferencing a NULL pointer
• Dereferencing a pointer returned by a "new" allocation of size zero
• Using pointers to objects whose lifetime has ended (for instance, stack allocated objects or deleted objects)
• Dereferencing a pointer that has not yet been definitely initialized
• Performing pointer arithmetic that yields a result outside the boundaries (either above or below) of an array.
• Dereferencing the pointer at a location beyond the end of an array.
• Converting pointers to objects of incompatible types
• Using memcpy to copy overlapping buffers.

Buffer overflows

• Reading or writing to an object or array at an offset that is negative, or beyond the size of that object (stack/heap overflow)

Integer Overflows

• Signed integer overflow
• Evaluating an expression that is not mathematically defined
• Left-shifting values by a negative amount (right shifts by negative amounts are implementation defined)
• Shifting values by an amount greater than or equal to the number of bits in the number (e.g. int64_t i = 1; i <<= 72 is undefined)

Types, Cast and Const

• Casting a numeric value into a value that can't be represented by the target type (either directly or via static_cast)
• Using an automatic variable before it has been definitely assigned (e.g., int i; i++; cout << i;)
• Using the value of any object of type other than volatile or sig_atomic_t at the receipt of a signal
• Attempting to modify a string literal or any other const object during its lifetime
• Concatenating a narrow with a wide string literal during preprocessing

Function and Template

• Not returning a value from a value-returning function (directly or by flowing off from a try-block)
• Multiple different definitions for the same entity (class, template, enumeration, inline function, static member function, etc.)
• Infinite recursion in the instantiation of templates
• Calling a function using different parameters or linkage to the parameters and linkage that the function is defined as using.

OOP

• Cascading destructions of objects with static storage duration
• The result of assigning to partially overlapping objects
• Recursively re-entering a function during the initialization of its static objects
• Making virtual function calls to pure virtual functions of an object from its constructor or destructor
• Referring to nonstatic members of objects that have not been constructed or have already been destructed

Source file and Preprocessing

• A non-empty source file that doesn't end with a newline, or ends with a backslash (prior to C++11)
• A backslash followed by a character that is not part of the specified escape codes in a character or string constant (this is implementation-defined in C++11).
• Exceeding implementation limits (number of nested blocks, number of functions in a program, available stack space ...)
• Preprocessor numeric values that can't be represented by a long int
• Preprocessing directive on the left side of a function-like macro definition
• Dynamically generating the defined token in a #if expression

To be classified

• Calling exit during the destruction of a program with static storage duration

Answer 3

The order that function parameters are evaluated is unspecified behavior. (This won't make your program crash, explode, or order pizza... unlike undefined behavior.)

The only requirement is that all parameters must be fully evaluated before the function is called.

---

This:

// The simple obvious one.
callFunc(getA(),getB());

Can be equivalent to this:

int a = getA();
int b = getB();
callFunc(a,b);

Or this:

int b = getB();
int a = getA();
callFunc(a,b);

It can be either; it's up to the compiler. The result can matter, depending on the side effects.

Answer 4

Assigning to a constant after stripping constness using const_cast<>:

const int i = 10; 
int *p =  const_cast<int*>( &i );
*p = 1234; //Undefined

Answer 5

The compiler is free to re-order the evaluation parts of an expression (assuming the meaning is unchanged).

From the original question:

a[i] = i++;

// This expression has three parts:
(a) a[i]
(b) i++
(c) Assign (b) to (a)

// (c) is guaranteed to happen after (a) and (b)
// But (a) and (b) can be done in either order.
// See n2521 Section 5.17
// (b) increments i but returns the original value.
// See n2521 Section 5.2.6
// Thus this expression can be written as:

int rhs  = i++;
int lhs& = a[i];
lhs = rhs;

// or
int lhs& = a[i];
int rhs  = i++;
lhs = rhs;

Double Checked locking. And one easy mistake to make.

A* a = new A("plop");

// Looks simple enough.
// But this can be split into three parts.
(a) allocate Memory
(b) Call constructor
(c) Assign value to 'a'

// No problem here:
// The compiler is allowed to do this:
(a) allocate Memory
(c) Assign value to 'a'
(b) Call constructor.
// This is because the whole thing is between two sequence points.

// So what is the big deal.
// Simple Double checked lock. (I know there are many other problems with this).
if (a == null) // (Point B)
{
    Lock   lock(mutex);
    if (a == null)
    {
        a = new A("Plop");  // (Point A).
    }
}
a->doStuff();

// Think of this situation.
// Thread 1: Reaches point A. Executes (a)(c)
// Thread 1: Is about to do (b) and gets unscheduled.
// Thread 2: Reaches point B. It can now skip the if block
//           Remember (c) has been done thus 'a' is not NULL.
//           But the memory has not been initialized.
//           Thread 2 now executes doStuff() on an uninitialized variable.

// The solution to this problem is to move the assignment of 'a'
// To the other side of the sequence point.
if (a == null) // (Point B)
{
    Lock   lock(mutex);
    if (a == null)
    {
        A* tmp = new A("Plop");  // (Point A).
        a = tmp;
    }
}
a->doStuff();

// Of course there are still other problems because of C++ support for
// threads. But hopefully these are addresses in the next standard.