Page History

...

In this example, a programmer working with a known <assert.h> is attempting to subvert the standard assert functionality so that assertions are always made, regardless of whether ndebug is setattempts to access their own verification functionality by suppressing the assert macro and instead sending control to an assert function.

#include <assert.h>

#undef assert

void myassert(int e) {
  __assert13(__// suppose the following is the definition of the assert()
// macro in <assert.h> and there is no function with the
// same name:
// #define assert(expr)   \
//   ((expr) ? (void)0 \
//           : (void)fprintf(stderr, "Assertion failed: %s:%d (%s): %s\n", \
//                            __FILE__, __LINE__, __assertfunc_function__, e);
}
, #expr))
//

void f(int i) {
  (assert)(0 < i);   // assert() macro suppressed, calling function assert()
}

Having this function and attempting to access it does not produce defined behaviorThis call results in undefined behavior, so the programmer can now never rely on assertions, even in debug builds.

Compliant Solution (assert)

In this solution, the programmer does not #undef a standard macro, and explicitly handles any release-build assertion checksThe programmer should place nonstandard verification in a function that does not conflict with the standard library macro assert.

#include <assert.h>

void myassertf(int e) {
  assertcustomAssert(e);
 // /*function otherwill verificationcheck ... */desired assertions
}

Noncompliant Code Example (Redefining errno)

...