Some errors, such as out-of-range values, might be the result of erroneous user input. Interactive programs typically handle such errors by rejecting the input and prompting the user for an acceptable value. Servers reject invalid user input by indicating an error to the client while at the same time continuing to service other clients' valid requests. All robust programs must be prepared to gracefully handle resource exhaustion, such as low memory or disk space conditions, at a minimum by preventing the loss of user data kept in volatile storage. Interactive programs may give the user the option to save data on an alternate medium, while network servers may respond by reducing throughput or otherwise degrading the quality of service. However, when certain kinds of errors are detected, such as irrecoverable logic errors, rather than risk data corruption by continuing to execute in an indeterminate state, the appropriate strategy may be for the system to quickly shut down, allowing the operator to start it afresh in a determinate state.
| Wiki Markup |
|---|
\[[ISO/IEC PDTRTR 24772|AA. Bibliography#ISO/IEC PDTRTR 24772]\], Section 6.47, "REU Termination strategy," says: |
When a fault is detected, there are many ways in which a system can react. The quickest and most noticeable way is to fail hard, also known as fail fast or fail stop. The reaction to a detected fault is to immediately halt the system. Alternatively, the reaction to a detected fault could be to fail soft. The system would keep working with the faults present, but the performance of the system would be degraded. Systems used in a high availability environment such as telephone switching centers, e-commerce, etc. would likely use a fail soft approach. What is actually done in a fail soft approach can vary depending on whether the system is used for safety critical or security critical purposes. For fail safe systems, such as flight controllers, traffic signals, or medical monitoring systems, there would be no effort to meet normal operational requirements, but rather to limit the damage or danger caused by the fault. A system that fails securely, such as cryptologic systems, would maintain maximum security when a fault is detected, possibly through a denial of service.
And also:
The reaction to a fault in a system can depend on the criticality of the part in which the fault originates. When a program consists of several tasks, the tasks each may be critical, or not. If a task is critical, it may or may not be restartable by the rest of the program. Ideally, a task which detects a fault within itself should be able to halt leaving its resources available for use by the rest of the program, halt clearing away its resources, or halt the entire program. The latency of any such communication, and whether other tasks can ignore such a communication, should be clearly specified. Having inconsistent reactions to a fault, such as the fault reaction to a crypto fault, can potentially be a vulnerability.
...
Calling exit() causes normal program termination to occur. Other than returning from main(), calling exit() is the typical way to end a program. The function takes one argument of type int, which should be either EXIT_SUCCESS or EXIT_FAILURE, indicating successful or unsuccessful termination, respectively. The value of EXIT_SUCCESS is guaranteed to be zero. C99 Section, 7.20.4.3 says, "If the value of status is zero or EXIT_SUCCESS, an implementation-defined form of the status successful termination is returned." The exit() function never returns.
...
Note that the behavior of a program that calls exit() from an atexit handler is undefined. (see See undefined behavior 172 in Annex J of C99). See also rule ENV32-C. All atexit handlers must return normally.)
return from main()
Returning from main() causes normal program termination to occur. This is the preferred way to terminate a program. Evaluating the return statement has the same effect as calling exit() with the same argument.
...
However, exiting from main is conditional on correctly handling all errors in a way that does not force premature termination. (see See recommendations ERR00-C. Adopt and implement a consistent and comprehensive error-handling policy and ERR05-C. Application-independent code should provide error detection without dictating error handling.).
_Exit()
Calling _Exit() causes normal program termination to occur. Like the exit() function _Exit() also takes one argument of type int and never returns. However, unlike exit(), whether _Exit() closes open streams, flushes stream buffers #1, or deletes temporary files is implementation-defined. Functions registered by atexit() are not executed.
| Wiki Markup |
|---|
<ac:structured-macro ac:name="anchor" ac:schema-version="1" ac:macro-id="4a66ecc03f123059-a492f96f-45134848-875aaed5-ba043fe1ed7ce999ca7eb399"><ac:parameter ac:name="">1</ac:parameter></ac:structured-macro>\[1\] Note that POSIX ^®^ strengthens the specification for {{_Exit()}} by prohibiting the function from flushing stream buffers. See the {{[documentation|http://www.opengroup.org/onlinepubs/9699919799/functions/_Exit.html]}} of the function in \[[IEEE Std 1003.1-2008|AA. Bibliography#IEEE Std 1003.1-2008]\]. |
...
As with _Exit(), whether open streams with unwritten buffered data are flushed #2, open streams are closed, or temporary files are removed is implementation-defined. Functions registered by atexit() are not executed. (see See recommendation ERR06-C. Understand the termination behavior of assert() and abort().).
| Wiki Markup |
|---|
<ac:structured-macro ac:name="anchor" ac:schema-version="1" ac:macro-id="4fde0d421cafb8fc-3aaf80f2-4cd043a9-87f587cc-7c4bea47b59216408438f7c9"><ac:parameter ac:name="">2</ac:parameter></ac:structured-macro>\[2\] Unlike in the case of {{\_Exit()}}, POSIX ^®^ explicitly permits but does not require implementations to flush stream buffers. See the {{[documentation|http://www.opengroup.org/onlinepubs/9699919799/functions/abort.html]}} of the function in \[[IEEE Std 1003.1-2008|AA. Bibliography#IEEE Std 1003.1-2008]\]. |
...
For more details on proper usage of abort(), see recommendation ERR06-C. Understand the termination behavior of assert() and abort().
...
Search for vulnerabilities resulting from the violation of this rule on the CERT website.
Other Languages
Related Guidelines
CERT This rule appears in the C++ Secure Coding Standard as : ERR04-CPP. Choose an appropriate termination strategy.
Bibliography
Wiki Markup
ISO/IEC PDTR 24772|AA. Bibliography#ISO/IEC PDTR 24772]\] "REU Termination strategy" \[[MITRE 07|AA. Bibliography#MITRE 07]\] [CWE ID 705|http://cwe.mitre.org/data/definitions/705.html], "Incorrect Control Flow Scoping"
MITRE CWE: CWE-705, "Incorrect Control Flow Scoping"
Bibliography
...
ERR03-C. Use runtime-constraint handlers when calling functions defined by TR24731-1 12. Error Handling (ERR)