JavaScript is not currently enabled, but is required for full CodeSonar manual search and browse functionality.

If you are viewing this file in your hub's Web GUI, enable JavaScript in your browser: you will also need it for GUI functionality.

If you opened this file directly from disk, your browser may be directly suppressing JavaScript functionality: certain browsers perform this suppression on local files (but not files delivered by web servers) for security reasons.

CodeSonar® 9.2p0 CONFIDENTIAL CodeSecure Inc

Tutorial: A Subtler Null Dereference Example

Bugs can arise because a program does not fully consider the effects of all legal inputs, or all possible return values from a called function. Detecting and isolating these bugs manually can be difficult, since they occur only rarely during execution of the program and may not be easily reproducible. CodeSonar's static analysis can be particularly helpful for finding such bugs.

The other of the two Null Pointer Dereference warnings in BasicProj.c, although vastly simplified, illustrates the kind of bug that can occur in practice.

You can navigate to the second Null Pointer Dereference warning report using the warning browse sequence navigation tools.

Source Code Excerpt

Screenshot fragment: source code excerpt

The annotations indicate the source of the problem (the code comments probably help too...):

Other events

The annotations displayed by default show how the problem arises when the case 2 branch of the switch statement is executed, but not how execution can reach this branch in the first place.

This time, the control flow annotation at line 13 notes that the rand() returns 2 in the execution being considered.

Note that this is a necessary condition for the warning, not a sufficient condition. Execution must pass through the case 2 branch of the switch statement for the null dereference to occur, but it must also be the case that malloc() returns a null pointer.

Conclusion

If rand() returns 2, the program takes the value returned by malloc() and starts using it to store data without first checking its value. Although the probability that malloc() will be unable to satisfy the memory allocation request is low (especially since the amount of memory requested is so small), it could happen and so the call to malloc() may return NULL, causing a null pointer dereference.

In the BasicProj.c source case 3 represents one way that we might correct the bug. CodeSonar does not report a null pointer dereference warning here, because q is only dereferenced if it is not NULL.

Next

 

To report problems with this documentation, please visit https://support.codesecure.com/.