Addressing one issue reveals another issue

SonarQube Server / Community Build
1

Hello!

We have noticed that addressing one issue can reveal another, previously hidden issue on the same line.

For example, when we addressed
before
(a critical code smell) then
after
(a major bug) appeared in its place.

From this we have two questions:

  1. Is the behavior where the bug was initially hidden expected?
  2. If one issue can hide another issue, then what logic governs which one gets shown?

The code above is compiled as C++17 and we use version 9.9.1 of SonarQube’s developer edition.

Thanks!

2

Hey @alxdvn

I suggest putting together a minimal reproducer that demonstrates this behavior. Screenshots aren’t a great starting point for debugging.

3

Hi,

I’m trying but no success so far.

Does your use of the term “debugging” imply that it would be a bug?

4

I assume it’s not expected behavior, (using NULL or nullptr shouldn’t affect whether or not a return will ever be executed), therefore both issues should appear at once.

5

Agreed.

Here’s a small example with which we can reproduce the behavior:

#include <cstddef>
#include <chrono>
#include <ctime>
#include <iostream>

void* foo()
{
    while (true)
    {
        const auto n = std::chrono::system_clock::now();
        const auto t = std::chrono::system_clock::to_time_t(n);
        std::cout << std::ctime(&t) << '\n';
        return nullptr;
    }
    return NULL;
}

int main()
{
    const auto p = foo();
    std::cout << p << '\n';
}

SonarQube flags the usage of NULL but does not report that return NULL; is unreachable:

NULL

However, replacing NULL with nullptr makes SonarQube report that the second return nullptr; is unreachable:

nullptr

8

Hi @alxdvn,

Thanks for raising this issue. This is indeed not the desired behavior for the code snippet you shared with us. Both issues related to the return statement return NULL; in foo (right after the loop) should be reported.

Whereas in C, NULL expands to ((void*)0), it expands to the compiler-built-in __null in C++, and this seems to cause the problem. Of course, this needs to be fixed. (I just checked using Compiler Explorer that manually replacing NULL by ((void*)0) causes both issues to be reported correctly, again.)

I will create a ticket and link it here such that you can track progress on this matter.

Best,
Philipp

9

Thanks again for reporting this.

Feel free to track progress at [CPP-5808] - Jira.

Philipp

11

Great, thank you @pdschbrt for looking into it.