What flow control?

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.

Exception Handling Patterns

Living with Exceptions

In Java, exceptions occur when some non-planned issue occurs that interrupts the normal flow of execution. Exception handling is accomplished in one of two general ways. The first is to simply allow the exception to propagate up the call stack. This is accomplished by adding the throws  keyword and a list of exception types to the method declaration. The second approach is to execute code that may throw  an exception inside of a try  block. Immediately following the try  block will be one or more catch  blocks that catch the different exception types that may occur in the preceding try block. The catch  block(s) may be followed by a finally  block that is used for cleanup.

Continue reading

Start getting up and running with Upstart

Recently, I needed to write a collection of upstart jobs to start the backend for a project at work. Upstart is a great tool for starting jobs in a particular sequence, but getting everything just right was challenging.

Continue reading

Welcome to Bespoke Bytes

This blog is an experiment in coding and writing. Writing has been a challenge during most of my career, despite writing of one form or another being a major professional activity. Please stay tuned for code examples, opinions, and the occasional rant.

Cheers — Hackworth.

© 2016 Bespoke Bytes

Theme by Anders NorénUp ↑