Page History

...

C99 provides several options for program termination, including exit(), returning from main(), _Exit(), and abort().

exit()

The C standard exit() function is typically used to end a program. It takes one argument, which should be either EXIT_SUCCESS or EXIT_FAILURE indicating normal or abnormal termination. Zero is equally portable and well understood. 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.

...

atexit() is only called by exit() or upon normal completion of main().

return from main()

Because main() is defined to have return type int, another valid exit strategy is to simply use a return statement.

...

However, making it out of main is conditional on correctly handling all errors in a way that does not force premature termination (see ERR00-C. Adopt and implement a consistent and comprehensive error handling policy and ERR05-AC. Application-independent code should provide error detection without dictating error handling).

_Exit()

A more abrupt function, _Exit() also takes one argument and never returns. The standard specifies that _Exit() also closes open file descriptors but does not specify whether _Exit() flushes file buffers or deletes temporary files. Functions registered by atexit() are not executed.

...

The _exit() function is a synonym for _Exit().

abort()

The quickest and most abrupt way to terminate a program, abort() takes no arguments and always signifies abnormal termination to the operating system.

...

Whether open streams with unwritten buffered data are flushed, open streams are closed, or temporary files are removed is implementation-defined. Functions registered by atexit() are not executed (see ERR06-AC. Understand the termination behavior of assert() and abort()).

Summary

...

Noncompliant Code Example

The abort() function should not be called if it is important to perform application-specific cleanup before exiting. In this non-compliant noncompliant code example, abort() is called after data is sent to an open file descriptor. The data may or may not actually get written to the file.

#include <stdlib.h>
#include <stdio.h>

int write_data(void) {
  const char const *filename = "hello.txt";
  FILE *f = fopen(filename, "w");
  if (f == NULL) {
    /* handle error */
  }
  fprintf(f, "Hello, World\n");
  /* ... */
  abort(); /* oops! data might not get written! */
  /* ... */
  return 0;
}

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

Compliant Solution

In this compliant solution, the call to abort() is replaced with exit(), which guarantees that buffered I/O data is flushed to the file descriptor and the file descriptor is properly closed.

#include <stdlib.h>
#include <stdio.h>

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

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

While this particular example benefits from calling exit() over abort(), there will be situations where abort() is the better choice. Usually this will occur if one does not want to close any file descriptors or call any handlers registered with atexit(), for instance, if the speed of terminating the program is critical.

Risk Analysis

Using abort() or _Exit() in place of exit() may leave written files in an inconsistent state, and may also leave sensitive temporary files on the file system.

Related Vulnerabilities

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

References

\[[ISO/IEC 9899:1999|AA. C References#ISO/IEC 9899-1999]\] Section 5.1.2.2.3, "Program termination," and Section 7.20.4, "Communication with the environment"
\[[ISO/IEC PDTR 24772|AA. C References#ISO/IEC PDTR 24772]\] "REU Termination strategy"

...

ERR03-C. Use runtime-constraint handlers when calling functions defined by TR24731-1      12. Error Handling (ERR)       ERR05-A. Application-independent code should provide error detection without dictating error handling Image Added