This is a false positive because cl is an unsigned long long int which means it cannot be less than 0, also it cannot overflow because now cp is reallocated to be (cl + LEN + 2) and the access is in cl + LEN +
Thanks for your version number. That’s not the latest version. Since you say the FP isn’t raised in SonarLint, I need to ask whether you run SonarLint in connected mode with SonarQube?
Why? When you’re in connected mode, SonarLint runs the rule implementation that’s on the server, and when you’re not in connected mode, you get the implementation version that shipped with SonarLint. So if your SonarLint version is newer than your SonarQube version, it’s possible to see these discrepancies. And it means that an upgrade of SonarQube would fix the problem for you! (And yes, I understand that you’re probably on the LTS for a reason. The new LTS comes out next month, on the 7th. )
So… Does this sound right to you? Are you using connected mode?
Yes, I am using connected mode. However, the bug still shows the false positive. Nonetheless, if the bug is fixed in newer versions of SonarQube it’s all good then.
For C and C++, SonarLint always uses the implementation it was shipped with, regardless of whether or not you’re in connected mode. So that explains perfectly what you’re seeing.