"Variable declared without initial value" even though it's assigned a value

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

I have what I think is a false positive, where it’s reported that a variable was declared without initial value, even though there is an assignment in the same line.

Version: SonarQube Developer 9.5.0.56709, SonarScanner 4.7.0.2747.

The code:

int AParam_ParseJsonSetCmd(const json_t *json, AParam_t *apar)
{
    int ret = APAR_RET_NOK;

    if (json && apar)
    {
        const char *jname = json_getName(json);
        const char *jval = json_getValue(json);
        const jsonType_t jtype = json_getType(json);
        const AParam_TableEntry_t *tab_entry = NULL;

        if (jname && jval && (JSON_TEXT == jtype || JSON_INTEGER == jtype || JSON_REAL == jtype))
        {

Reported rule is c:S836 (Variables should be initialized before use)

The report looks like this:

grafik
grafik1267×240 56 KB

The reported bug is the use of jname in the if clause, but what I think is a wrong analysis is the declaration without initial value, even though the declaration assigns the return value of the function json_getName(). That function is from tiny-json, and looks like this:

static inline char const* json_getName( json_t const* json ) {
    return json->name;
}
5

Hi @kkoop !
Welcome to the community! This is a very nicely formatted FP report, big kudos!

Unfortunately, I still cannot reproduce the issue based on the code snippets you shared. Would you mind creating a reproducer file that contains all the relevant code and environment?
For that you’ll need to:

  • Add the reproducer option to the scanner configuration:
    sonar.cfamily.reproducer= “Full path to the .cpp file that has or include the file that has the false-positive”. So in your example that would be “B-Board/BMS/Application/ABoardParam.c”
  • Re-running the scanner should generate a file named sonar-cfamily.reproducer in the project folder.
  • Please share this file. if you think this file contains private information we can send it privately.
6

I’ve now run the analysis with the reproducer option, and even though the analysis fails with an IllegalStateException, a file was created which I’ll try to attach here.
sonar-cfamily-reproducer.zip (361.8 KB)

7

Thank you for the reproducer file, and nevermind the crash - it is expected when a reproducer is requested.

Using the reproducer I was able to discover that with your compiler configuration, the inline keyword is not recognized and hence the compiler emits a parsing error on the definition of json_getName.
Our engine cannot work reliably in the presence of parsing errors and sometimes it produces false positives like the one you’ve reported due to an incomplete understanding of the non-conformant source code.
In order to see these parsing errors, you can enable rule S2260 in your quality profile, and filter issues of this rule.

With all the above, it still would make more sense to suppress the reporting here, if possible, so I opened a ticket to track that: [CPP-3760] - Jira

9

A second question here is “Why is inline keyword not recognized?”. The answer lies in the predefined macro provided by the Diab compiler:

#define __STDC_VERSION__ 199409L

This value corresponds to a C standard preceding C99, and inline was introduced in C99. One potential cause for it is the set of cmdline arguments of the compiler, that includes these two (as per build-wrapper-dump.json)

-Xdialect-c99 -Xdialect-c++11

I suggest you to remove the -Xdialect-c++11 option (which might be overriding the preceding one) from the build-wrapper capture to check if that fixes the C standard, and if it helps, remove it from your build script for C files.

10

Indeed removing -Xdialect-c++11 makes the bug disappear from SonarQube.

I still don’t fully understand where the error when parsing inline appears, because compilation works fine, with no compiler error or warning in this line.

11

It might be that our driver does not model the Diab compiler correctly in this aspect. For many compilers, options like -Xdialect... override each other and only the last one in the command line is taken into consideration. Do you confirm that Diab uses both of the options?
I.e., what is the value of the __STDC_VERSION__ macro if you pass both -Xdialect-c99 -Xdialect-c++11 during the compilation of your C file, and what is the value of __cplusplus macro if you pass the same two options when compiling your C++ file?

12

__STDC_VERSION__ is 199901 with both -Xdialect-c99 -Xdialect-c++11 and -Xdialect-c99 alone. We currently only have C files in the codebase, __cplusplus is never defined there, even with -Xdialect-c++11.

1 Like
13

Thank you. That means our model of Diab compiler is incorrect here: [CPP-3765] - Jira

1 Like
14

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.