Rule S3949 "Integral operations should not overflow" false positives

We are currently using SonarQube Developer Edition Version 8.6.1 (build 40680) with SonarScanner
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;
        case BAUD_SELECTION_19200:
        case BAUD_SELECTION_38400:
        case BAUD_SELECTION_57600:
        case BAUD_SELECTION_115200: // Is flagged as a violation (115200 to 49664)
            valid = false;
    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.

For reference,
typedef unsigned long uint32_t;

Hello @Wes ,

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)

Thank you

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)
  • long = 16-bit (incorrect, should be 32-bit)

For reference on the C2000 processor see 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”,

Hi @Malcolm_Nixon,

This thread is old. My recommendation is always to create a new thread with a detailed description rather than commenting on a non-active thread.