Sonar missed catching null pointer accesses

Clean Code Report False-positive / False-negative...
,
1

Trying to check if sonar is able to catch some obvious bad code. Wrote following sample bad code:

 18         char *ptr1 = NULL;
 19         char *ptr2 = NULL;
 20         char *temp = NULL;
 21         char line[] = "testingwithoutcoloninline";
 22         if (!bitmap_max_entries) {
 23                 temp = strpbrk(line, ";");
 24                 *temp = '\0';
 25                 *ptr1 = 'a';
 26                 *ptr2 = 'a';
 27                 test_func(ptr2);
 28         }

It is analyzing and catching only one bug at line# 25 as "Dereference of null pointer (loaded from variable ‘ptr1’) ".

I am expecting it to catch the same at line #24 (strpbrk() may return null) and at line #26 ( similar case as that of line #25)

I tried cppcheck and it catches all of it.

I am not sure if I am expecting too much or if there is something not configured properly in sonar. Can someone please help?

2

Hi,

For C, C++, and Objective-C, we stop evaluating after we hit the first thing that will kill the program. That’s why we detected the first null-pointer dereference but not the other two. The first one is enough to stop execution, so control flow will never get to the other two.

 
HTH,
Ann

1 Like
3

so if I have 100 more bugs or errors sitting behing this hit which can kill the program, those will not be reported? Will It not lead to showing wrong quality statistics?
I will have to fix and run sonar one by one 100 times to unearth all issues?
is there any way to disable this and have it report all issues at once so that we can see report with all issues and fix all of them at once.

7

Hi @Vimal_Agrawal

The first detected bug causes undefined behavior that renders the program meaningless from C or C++ point of view. Our analyzer strives to adhere to the formal semantics of the language, and once it encounters null-pointer dereference on line #25 the language semantics throws hands in the air and gives up. The analyzer cannot justify any additional report about the semantics of the code.

There is nothing you can configure to change that in Sonar. However, you can change your code: we analyze independently functions that do not call each other. You can put each bug into a separate function. Then Sonar will detect them.

Other analyzers, such as cppcheck, approximate the code semantics and digress from the language specification when they report further bugs in this function.

I agree that it is inconvenient to rerun the analyzer 100 times to fix 100 consecutive bugs in a function. Yet, in practice, it happens only in specifically crafted code snippets. When you use the analyzer alongside your development, you rarely introduce multiple bugs in the same execution flow with a single change.

Note that line #24 is different. strpbrk can return null as can many other functions. In many cases, the context is such that the developer can be confident the return value is benign. For example, here ; could be guaranteed to be present in line, so strpbrk would never return null.

In most such cases, our analyzer, steering away from annoying false positives, gives the developer the benefit of the doubt and does not report a potential bug, assuming the context is such that the return value is within the bounds expected by the surrounding code.

In this particular case, ; is actually not in line (which is known statically) and it is a genuine false negative caused by the fact that our model of strpbrk is shallow.

4 Likes