The assert()  macro is not a flow control mechanism (and NULL != 0 ).

An interesting vulnerability in systemd appears to be a consequence of the failure to understand that assert() is not and should not be used as flow control. In the code the authors had the following function:

In line 7 of the snippet there is an assertion to check if n > 0 , in this case n  is the size of  a buffer.  Since a buffer of size 0 causes systemd to crash on some systems, this is a good check. There are however two serious problems with the code as written:

  1. If systemd is compiled with the -DNDEBUG  compiler flag, then the assert()  macro will not generate any code so the check doesn’t happen.
  2. If systemd is compiled without the -DNDEBUG  flag, then if the assertion fails the program will abort.

For a critical software component, both problems are extremely undesirable. The core of the problem appears to be the use of the assert()  macro as a flow control mechanism. If it critically important for the value of n  to be checked, then use a real comparison with explicit error handling.

An additional item of concern is the use of assert()  macros where there is an implicit assumption that   NULL == 0 . At a minimum, comparisons of a pointer to NULL  should be done explicitly.

Assuming that the conditions implied by the assert()  macro usage is correct, the code should be rewritten as:

In keeping with good practice, this code will check important conditions regardless of the presence of the  -DNDEBUG  compiler flag. Additionally, in keeping with the C11 standard (ISO/IEC 9899:201xNULL is not assumed to be a zero of any type.