Issue is properly flagged when compiling only the source code file (.c → .o)
Issue it not flagged when same code is built inside a larger project.
Are you using
SonarQube Server 2026.1.3
How can we reproduce the problem? Give us a self-contained snippet of code (formatted text, no screenshots)
Issue here is that the same code does not trig the c:S2259 when built as part of a large C project using makefile and gcc-arm.
Overall, below is a code excerpt (part of larger .c file). Issue is easily spotable:
inv_iam_status_cb()
When setting *odr_event_set=true, properly check for NULL
When setting *odr_event_set=false, missing check for NULL
inv_iam_device_reset() explicitly calls inv_iam_status_cb with NULL
int inv_iam_status_cb(struct inv_iam * s,volatile int *odr_event_set)
{
int status = INV_ERROR_SUCCESS;
uint16_t int_status = 0;
status = inv_iam_rd_int_status(s,&int_status);
if(!status)
{
if ((int_status&BIT_ODR_EVENT_MASK) && (odr_event_set!=NULL))
{
*odr_event_set = true;
return status;
}
}
*odr_event_set = false;
return status;
}
int inv_iam_device_reset(struct inv_iam * s)
{
int status = 0;
// ...
while(...)
{
// ...
inv_iam_status_cb(s,NULL);
if(...)
break;
}
return INV_ERROR_SUCCESS;
}
Not sure how can i move forward with this one, any guidance would be appreciated.
Thanks in advance for your help
I have discussed with the team, there is no IP so i could be able to share the code using a public github repo, also providing relevant inputs to easily navigate. We don’t have public sonarqube cloud account.
Hey @scm_invn, thanks for the detailed report! If you can share the project via GitHub repo or even zip file attached here, that’s be great, because otherwise our devs would have to be guessing what conditions might be at play in your project to affect the detection of this issue.
Hey @scm_invn, there is actually a more practical way to proceed: generating what we call a CFamily reproducer archive.
This is achieved by running a normal clean build and analysis of your project with the addition of this parameter: -Dsonar.cfamily.reproducer=/absolute/path/to/the-file.c. The path must point to the compilation unit (.c file) and must exactly match the path printed in the verbose CFamily sensor log (-Dsonar.verbose=true), including slash type (/ or \) and any unusual .. path segments.
The scanner will intentionally stop after producing the archive and print its exact location, the name will be sonar-cfamily-reproducer.tar.xz. Could you attach this file here?
Thanks @scm_invn! Yes it can be tricky to get the path right sometimes because it must be exactly the path that the scanner sees. Great to hear you managed to get it.
What can i do more to help? You need information about compiler/toolchain?
No need, the reproducer already contains all the information we need.
Unfortunately, we were unable to reproduce the false negative. Running both reproducers on our side reports c:S2259 at the expected dereference.
We considered whether caching could explain the difference between the standalone-file and whole-project analyses. However, the logs bundled with both reproducer archives show that the analysis cache was unavailable.
Could you confirm whether the original whole-project analysis, in which the issue was not reported, also ran with caching disabled? In particular, was it the same scan configuration used to generate the reproducer?
If caching can be ruled out, it would be helpful if you could share the project in a GitHub repository, together with instructions for building and analyzing it. We can then follow those instructions and investigate further.
If you prefer, you can also share the project privately by sending me a message.