The vulnerabilities described in ISO/IEC 24772-1:2019 clause 6.36 exist in C++, however, C++ provides a mitigation.
C++ includes the C library, especially the header <cerrno> and thus shares C’s issues with the global error-reporting variable errno. See ISO/IEC TR 24772-3:2020, clause 6.36 for details and guidance.
In addition to errno some C++ library features expose error conditions indirectly via a side-effect on the object the operation failed with or via side-effect on a reference parameter. For example, input stream objects will go into a fail state, when formatted input cannot be performed. Without resetting that fail-state of a stream, further input will continue to fail, that can cause further failures when a failure is ignored. Streams provide a non-default mode to throw exceptions on failure. Another example of error reporting via a side-effect is the filesystem library that provides overloads that take a non-const reference of std::error_code.
In general, reporting errors as side-effects, in the worst case via a global state, is too easy to accidentally ignore by developers, leading to further consistency problems in the continued execution of the program.
By default, C++ has the C weakness of permitting the call to a function that returns an error code without capturing the return value in a variable.
errnum foo( int a, int b);
. . .
foo(x, y); // failure to capture the return error code.C++ offers as a mitigating mechanism the [[nodiscard]] attribute. This attribute indicates that the function result must not be discarded. Ignoring the result of a function marked [[nodiscard]] causes a compiler warning.
[[nodiscard]] errnum foo( int a, int b);
. . .
foo(x, y); // compile error.
if( auto e = foo(a,b); e == 0) { // no compile error
// success
}
else {
// handle errors
}In addition, the C++ library provides mechanism to extend the return type of a function with extra values for denoting an error. The simplest case is std::optional<T> that extends T with an “empty” state. Callers must check the result of functions returning an optional for the empty state, before accessing its value. This increases the chances that a reported error is detected by the caller. If additional information of the error has to be returned to the caller std::expected<T,AnErrorCode> or alternatively std::variant<T,AnErrorCode> can be used.
C++ offers a set of library-defined exceptions for error conditions that may be detected by checks that are performed by the standard library. In addition, the programmer may define exceptions that are appropriate for their application. These exceptions are handled using an exception handler. Exceptions may be handled in the environment where the exception occurs or may be propagated out to an enclosing scope. Exceptions that are never handled in the program result in abnormal termination of the application. In this case, it is implementation-defined whether the destruction of local objects (stack unwinding) occurs. An unhandled exception that occurs in a thread also results in the abnormal termination of the application. See 6.62 Concurrency - Premature Termination [CGS] for issues related to thread or process termination. An exception propagating out of a coroutine causes the coroutine to end in an unresumable state and the exception is not further propagated.
To avoid the vulnerability or mitigate its ill effects, C++ developers can:
Follow the avoidance mechanisms of ISO/IEC 24772-1 subclause 6.36.5;
Develop an error management strategy, including error-detection, error-reporting, and error-handling,that, based on context, selects the most appropriate mechanism(s) from the different ones provided by C++;
Prohibit error handling based on unsynchronized global state;
Avoid the use of errno, but if it cannot be avoided, follow the avoidance mechanisms of ISO/IEC TR 24772-3 subclause 6.36.2;
Use static analysis tools to detect and report missing or ineffective error detection or handling;
Use [[nodiscard]] to prevent callers from ignoring error values and configure your compiler to report violations as errors, such as -Werror;
Use a try-catch function body for main or any thread-entry function with a catch(...) handler to guarantee stack unwinding, which guarantees the destruction of all local objects, and permits control of the ultimate termination of the thread or program;
Use a try-catch body for a coroutine with a catch handler to prevent silent termination of the coroutine in the case of an exception, or alternatively use a coroutine type that properly supports the case where the coroutine ends with an exception;
Consider controlled termination as a last resort strategy for main or for noexcept functions;
Consider the use of std::exception_ptr or an object encapsulating its mechanics like std::future to transport an exception from one thread to another thread for further processing.