Rule cpp:S836 reports a bug without a reason

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

Hi,

I’m new to the community and the tool, and probably not getting the things right,
but after several similar cases, I finally decided to ask someone.

here I have this code
image

The bug report is not completely unreasonable, as LoadIcon() may return NULL,
but the message that is shown is definitely not correct. How can hIcon this be an uninitialized value ?

I’m using SonarCube 9.6.1 (build 59531)

2

Hey there.

Welcome to our Community! I’ve moved your post to the section for reporting false-postives.

Please update your thread with a text-based code sample that reproduces the issue (not a screenshot)

3

I did some investigation work. It looks that if the RHS of the expression is a macro, the assignment is not detected by the software.

LoadIcon is a macro that redirects to either LoadIconA or LoadIconW like that:

#ifdef UNICODE
#define LoadIcon  LoadIconW
#else
#define LoadIcon  LoadIconA
#endif // !UNICODE

and then the actual code that reproduces the behavior

HICON hIcon = LoadIcon(AfxGetInstanceHandle(), MAKEINTRESOURCE(IDI_ICON1));
//reports cpp:S836: "1st function call argument is an uninitialized value"
SetIcon(hIcon, TRUE);

there is another trigger to the same behavior - a templated function call

class myClass
{
public:
    template<UINT A, UINT B> static const char *ID2Type(UINT nID);
};

template<UINT A, UINT B> inline const char *myClass::ID2Type(UINT nID)
{
	switch (nID)
	{
	case A:  return "TypeA";
	case B:  return "TypeB";
	default: return nullptr;
	}
}

void main()
{
    const char *type = myClass::ID2Type<1,2>(1);
    // reports cpp:S836 "Branch condition evaluates to a garbage value"
    if(!type)
        return 1;
    return 0;
}
4

Any updates on this?

We are seeing many similar false positives where a macro is seemingly not being expanded by the scan.

This is quite a big limitation?

5

It seems this fell off my plate at the beginning of the year.

Hey @mickdo

What version of SonarQube are you using? Can you share an example like @Nikolay_Bakalov?

6

Hi Colin,

actually it looks like the issue was down to some of the compiler includes not being correct for the build wrapper (my fault, not a SonarQube problem).

The includes were distant from the macros in question, but it seemed to be enough to throw off the scan and generate some spurious false positives there.

All good now! Thanks for the quick response

1 Like