Page History

Throwing an exception requires collaboration between the execution of the throw expression and the passing of control to the appropriate catch statement, if one applies. This collaboration takes the form of runtime logic used to calculate the correct handler for the exception and is an implementation detail specific to the platform. For code compiled by a single C++ compiler, the details of how to throw and catch exceptions can be safely ignored. However, when throwing an exception across execution boundaries, care must be taken to ensure the runtime logic used is compatible between differing sides of the execution boundary.

An execution boundary is the delimitation between code compiled by differing compilers, including different versions of a compiler produced by the same vendor. For instance, a function may be declared in a header file but defined in a library that is loaded at runtime. The execution boundary is between the call site in the executable and the function implementation in the library. Such boundaries are also called ABI (application binary interface) boundaries because they relate to the interoperability of application binaries.

 Throw an exception across an execution boundary only when both sides of the execution boundary use the same ABI for exception handling.

Noncompliant Code Example

In this noncompliant code example, an exception is thrown from a library function to signal an error. Despite the exception being a scalar type (and thus implicitly conforming to EXP60-CPP. Do not pass a nonstandard-layout type object across execution boundaries), this code can still result in abnormal program execution if the library and application adhere to different ABIs.

// library.h
void func() noexcept(false); // Implemented by the library
 
// library.cpp
void func() noexcept(false) {
  // ...
  if (/* ... */) {
    throw 42;
  }
}
 
// application.cpp
#include "library.h"

void f() {
  try {
    func();
  } catch(int &e) {
    // Handle error
  }
}

Implementation Details

If the library code is compiled (with modification to account for mangling differences) with GCC 4.9 on a default installation of MinGW-w64 without special compiler flags, the exception throw will rely on the zero-cost, table-based exception model that is based on DWARF and uses the Itanium ABI. If the application code is compiled with Microsoft Visual Studio 2013, the catch handler will be based on Structured Exception Handling and the Microsoft ABI. These two exception-handling formats are incompatible, as are the ABIs, resulting in abnormal program behavior. Specifically, the exception thrown by the library is not caught by the application, and std::terminate() is eventually called.

Compliant Solution

In this compliant solution, the error from the library function is indicated by a return value instead of an exception. Using Microsoft Visual Studio (or GCC) to compile both the library and the application would also be a compliant solution because the same exception-handling machinery and ABI would be used on both sides of the execution boundary.

// library.h
int func() noexcept(true); // Implemented by the library

// library.cpp
int func() noexcept(true) {
  // ...
  if (/* ... */) {
    return 42;
  }
  // ...
  return 0;
}
 
// application.cpp
#include "library.h"

void f() {
  if (int err = func()) {
    // Handle error
  }
}

Risk Assessment

The effects of throwing an exception across execution boundaries depends on the implementation details of the exception-handling mechanics. They can range from correct or benign behavior to undefined behavior.

Automated Detection

Related Vulnerabilities

Search for other vulnerabilities resulting from the violation of this rule on the CERT website.

Related Guidelines

Bibliography