Page History

Wiki MarkupC99 defines {{assert()}} to have the following behavior \[[ISO/IEC 9899-1999|AA. C References#ISO/IEC 9899-1999]\]The C Standard, subclause 7.2.1.1 [ISO/IEC 9899:2011], defines assert() to have the following behavior:

The assert macro puts diagnostic tests into programs; it expands to a void expression. When it is executed, if expression (which shall have a scalar type) is false (that is, compares equal to 0), the assert macro writes information about the particular call that failed (including the text of the argument, the name of the source file, the source line number, and the name of the enclosing function — the function—the latter are respectively the values of the preprocessing pre-processing macros __FILE__ and __LINE__ and of the identifier __func__) on the standard error stream in an implementation-defined format. It then calls the abort function.

Since Because assert() calls abort(), any cleanup functions registered with atexit() will are not be called. If the intention of the programmer is to properly cleanup clean up in the case of a failed assertion, a signal handler that calls exit() should be installed to handle SIGABRT.

See \[[ERR04-A. Choose an appropriate termination strategy]\] for more on {{abort()}} and terminating out of programs, and \[[MSC11-A. Incorporate diagnostic tests using assertions]\] for more on the {{assert()}} macro.

...

then runtime assertions should be replaced with static assertions where possible. (See DCL03-C. Use a static assertion to test the value of a constant expression.) When the assertion is based on runtime data, the assert should be replaced with a runtime check that implements the adopted error strategy (see ERR00-C. Adopt and implement a consistent and comprehensive error-handling policy).

See ERR04-C. Choose an appropriate termination strategy for more information on program termination strategies and MSC11-C. Incorporate diagnostic tests using assertions for more information on using the assert() macro.

Noncompliant Code Example

This noncompliant code example defines a function that is called before the program exits to clean up:

void cleanup(void) {
  /* deleteDelete temporary files, restore consistent state, etc. */
}

int main(void) {
  if (atexit(cleanup);) != 0) {
    /* Handle error */
  }

  /* ... */

  assert(/* somethingSomething bad didn't happen */);

  /* ... */
}

If the assert() However, the code also has an assert, and if the assertion fails, the cleanup() will function is not be called.

Compliant Solution

In this compliant solution, the call to assert() is replaced with an if statement that calls exit() to ensure that the proper termination routines are run:

void sigabrt_handler(int signum) {
  exit(EXIT_FAILURE);
}

void cleanup(void) {
  /* deleteDelete temporary files, restore consistent state, etc. */
}

int main(void) {
  if (atexit(cleanup);
  signal(SIGABRT, sigabrt_handler);

!= 0) {
    /* Handle ...error */

  assert(/* something bad didn't happen */);}

  /* ... */
}

...

...

...

if 

...

(/* 

...

Something 

...

bad 

...

happened 

...

*/) {
    exit(EXIT_FAILURE);
  }

  /* ... */
}

Risk Assessment

Unsafe use

Risk Analysis

Unsafe usage of abort() may leave files written in an inconsistent state. It may also leave sensitive temporary files on the filesystemfile system.

Automated Detection

Related Vulnerabilities

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

References

...

Related Guidelines

Bibliography

...

...

...

Image Added Image Added Image Added {{assert}} macro", 7.20.4.1, "The {{abort}} function"ERR05-A. Application-independent code must provide error detection without dictating error handling      12. Error Handling (ERR)       ERR30-C. Set errno to zero before calling a function, and use it only after the function returns a value indicating failure