Page History

...

Programmers should never attempt to access anything underlying any of these macros.

Noncompliant Code Example (assert)

In this example, a programmer attempts to access their own verification functionality by suppressing the assert macro and instead sending control to a user-defined assert() function.

...

Having this function and attempting to access it produces undefined behavior.

Compliant Solution (assert)

The programmer should place nonstandard verification in a function that does not conflict with the standard library macro assert, e.g. myassert().

#include <myassert.h>
#include <assert.h>

void fullAssert(int e) {
  assert(0 < e); // standard library assert()
  myassert(e); // well defined custom assertion function
}

Noncompliant Code Example (redefining errno)

Legacy code is apt to include an incorrect declaration such as the following.

extern int errno;

Compliant Solution (redefining errno)

The correct way to declare errno is to include the header <errno.h>.

...

Implementations conforming to C99 are required to declare errno in <errno.h>, although some historic implementations failed to do so.

Risk Assessment

Accessing objects or function underlying these macros does not produce defined behavior, which may lead to incorrect or unexpected program behavior.

References

\[[ISO/IEC 9899:1999|AA. References#ISO/IEC 9899-1999]\], all sections indicated by the [undefined behavior items |CC. Undefined Behavior] noted above.