We are currently using SonarQube Developer Edition Version 8.6.1 (build 40680) with SonarScanner 4.6.0.2311
Our code base uses TI’s C2000 compilers with Code Composer Studio (Eclipse) for builds
Our false positives appear to occur with enumerations and associated numerical type.
One example shown below is given an indication that
“overflow converting case value to switch condition type (115200 to 49664)” but the condition type is 32-bit which will fit the 115200 value.
bool_t IsBaudValid(uint32_t value)
{
bool_t valid = true;
switch(value)
{
case BAUD_SELECTION_19200:
case BAUD_SELECTION_38400:
case BAUD_SELECTION_57600:
case BAUD_SELECTION_115200: // Is flagged as a violation (115200 to 49664)
break;
default:
valid = false;
break;
}
return valid;
}
In another instance, we had an enumeration that was longer than 256 items and when it grew larger than 256 items the 256th item’s commit line was tagged with a violation, “overflow in enumeration value”.
Note that we see this on our local machines and after the analyzer build on our server with the bugs showing up on the SonarQube project’s Issues.
Thanks for reporting these false positives.
I don’t succeed in reproducing the issues on my side so do you think you could create a small reproducer for each of those two false positives?
To generate a reproducer file:
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"
Re-running the scanner should generate a file named sonar-cfamily.reproducer in the project folder.
Please share this file (I can send you a PM if you want to share it privately)
I’ve got a similar issue with running SonarQube 9.3 on a C2000 project. I have around 300-400 warnings of the type:
implicit conversion from ‘long long’ to ‘uint32_t’ (aka ‘unsigned long’) changes value from 100000 to 34464
implicit conversion from ‘long’ to ‘const unsigned int’ changes value from 1000 to 232
implicit conversion from ‘unsigned long’ to ‘const uint16_t’ (aka ‘const unsigned int’) changes value from 56385 to 65
The C2000 is a 16-bit DSP with no support for 8-bit data types. As such the standard C types are as follows:
char = 16-bit
int = 16-bit
long = 32-bit
Unfortunately it looks like SonarQube has incorrect data regarding this processors configuration, and (based on the truncation values) erroneously makes the following assumptions:
char = 8-bit (incorrect, no 8-bit types supported, should be 16-bit)
int = 8-bit (incorrect, no 8-bit types supported, should be 16-bit)
For reference on the C2000 processor see https://www.ti.com/lit/ug/spru514r/spru514r.pdf section 6.4 which lists the sizes of every C data type, and also includes the following interesting foot-note:
NOTE: TMS320C28x Byte is 16 Bits
By ANSI/ISO C definition, the sizeof operator yields the number of bytes required to store an object. ANSI/ISO further stipulates that when sizeof is applied to char, the result is 1. Since the TMS320C28x char is 16 bits (to make it separately addressable), a byte is also 16 bits. This yields results you may not expect; for example, size of (int) = = 1 (not 2). TMS320C28x bytes and words are equivalent (16 bits).
I can’t easily generate the sonar.cfamily.reproducer, but I can share some lines from the build-wrapper-dump.json which show it’s identified the compiler as TI. The fact it’s the cl2000 compiler is enough (even without the -v28 argument) to identify it’s for the C2000 processor and deduce the correct types: > “compiler”:“texas”, > “executable”:“C:\ti\ccs1040\ccs\tools\compiler\ti-cgt-c2000_20.12.0.STS\bin\cl2000.exe”, > “cmd”: [ > “C:/ti/ccs1040/ccs/tools/compiler/ti-cgt-c2000_20.12.0.STS/bin/cl2000”, > “-v28”, > “-ml”, > “-mt”, > “–cla_support=cla1”, > “–float_support=fpu32”, > “–tmu_support=tmu0”, > “–vcu_support=vcu2”,