Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

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 alternative medium, whereas 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.

ISO/IEC TR 24772:2013, Section 6.39, "Termination Strategy [REU]," [ISO/IEC TR 24772:2013], 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, or other "always available" applications 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.

...

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 0. The C Standard,  Section subclause 7.22.4.4 [ISO/IEC 9899:2011], 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.

Code Block
bgColor#ccccff
langc
#include <stdlib.h>
/* ... */

if (/* somethingSomething really bad happened */) {
  exit(EXIT_FAILURE);
}

...

Note that the behavior of a program that calls exit() from an atexit handler is undefined. (See undefined behavior 182 in Annex J of the C Standard. See also ENV32-C. All atexit exit handlers must return normally.)

return from main()

Returning from main() causes normal program termination to occur, which is the preferred way to terminate a program. Evaluating the return statement has the same effect as calling exit() with the same argument.

Code Block
bgColor#ccccff
langc
#include <stdlib.h>
 
int main(int argc, char **argv) {
  /* ... */
  if (/* somethingSomething really bad happened */) {
    return EXIT_FAILURE;
  }
  /* ... */
  return EXIT_SUCCESS;
}

The C Standard, Section subclause 5.1.2.2.3 [ISO/IEC 9899:2011], has this to say about returning from main():

...

Code Block
bgColor#ccccff
langc
#include <stdlib.h>
/* ... */

if (/* somethingSomething really bad happened */) {
  _Exit(EXIT_FAILURE);
}

...

Code Block
bgColor#ccccff
langc
#include <stdlib.h>
/* ... */

if (/* somethingSomething really bad happened */) {
  abort();
}

...

Anchor
2
2
[2] Unlike in the case of _Exit(), POSIX explicitly permits but does not require implementations to flush stream buffers. See the documentation of the function in The Open Group Base Specifications Issue 7, IEEE Std 1003.1, 2008 Edition [IEEE Std 1003.1-2008].

...

Code Block
bgColor#ccccff
langc
#include <stdlib.h>
#include <stdio.h>

int write_data(void) {
  const char *filename = "hello.txt";
  FILE *f = fopen(filename, "w");
  if (f == NULL) {
    /* Handle error */
  }
  fprintf(f, "Hello, World\n");
  /* ... */
  exit(EXIT_FAILURE); /* Writes data and closes f. */
  /* ... */
  return 0;
}

int main(void) {
  write_data();
  return EXIT_SUCCESS;
}

...

Recommendation

Severity

Likelihood

Remediation Cost

Priority

Level

ERR04-C

mediumMedium

probableProbable

highHigh

P4

L3

Related Vulnerabilities

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

...

Bibliography

[ISO/IEC 9899:2011]Section Subclause 5.1.2.2.3, "Program Termination"
Section Subclause 7.22.4, "Communication with the Environment"

...