Incompatiblity between rule c:S995 and low level driver embedded C software

SonarQube
,
1

Hi,

we are using SonarQube 8.4.0.35506 with the sonar scanner for C language.

In our analysis, the report indicates the following message corresponding to rule c:S995 :
“The pointee of “rx” should be const-qualified; the type of “rx” is “unsigned char *”.”

But in fact, we must not use “const unsigned char *” because the value within our pointer is modified as follow:

void SPI_transmit(unsigned char tx, unsigned char * rx)
{
    SPDR = tx;
    while(!(SPSR & (1 << SPIF)));
    *rx = SPDR;
}

“SPDR” represents the data register of the SPI peripheral and is defined as:

#define SPDR      _SFR_IO8(0x0F)
#define _SFR_IO8(io_addr) _MMIO_BYTE((io_addr) + __SFR_OFFSET)
#define _MMIO_BYTE(mem_addr) (*(volatile uint8_t *)(mem_addr))
#define __SFR_OFFSET 0x20

We do not understand why the analysis raises a code smell for it and, because we have developed a lot of functions like this one, we have a lot of code smells raised about this point. May we have missed something or could it be a false positive ?

Thank you in advance.
Alex

3

Hello @alexandremalecot,

Welcome to the community!

I wasn’t able to reproduce this on my side. It might because It is related to the definition of SPSR and SPIF that I don’t have. If they are not complicated can you share them?

If not, can you spot the file that contains this false positive and generate its reproducer. To generate the reproducer:
add reproducer option to the scanner configuration:
sonar.cfamily.reproducer= "Full path to the .cpp/.c file that contains the false-positive or include the header that contains the false-positive"
Running the scanner again should create a file named sonar-cfamily.reproducer in the project folder.
This file will help me in debugging the issue. You can share it privately if you prefer.

Thanks,

4

Hi @Abbas,
Thanks for you answer.
Here I complete the macro definitions with the ones you asked for:

#define SPIF         7
#define SPSR      _SFR_IO8(0x0E)
#define SPDR      _SFR_IO8(0x0F)
#define _SFR_IO8(io_addr) _MMIO_BYTE((io_addr) + __SFR_OFFSET)
#define _MMIO_BYTE(mem_addr) (*(volatile uint8_t *)(mem_addr))
#define __SFR_OFFSET 0x20

I am really sorry but I did not succeed to generate the report with the reproducer option… Even with the full relative path from the location where we launch our Makefile or with the full absolute path of the spi.c file in which there is the issue. The error message is the following:

The sonar.cfamily.reproducer property was set but no matching file was found. The property was set to:
  src/drivers/spi/spi.c

with the sonar-scanner.properties:

sonar.projectKey=projectKey/Name
sonar.projectName=projectKey/Name
sonar.projectVersion=1.0
sonar.sources=src
sonar.cfamily.build-wrapper-output=buildWrapperOutputDirectory
sonar.sourceEncoding=UTF-8
sonar.branch.name=Branch

sonar.cfamily.reproducer=src/drivers/spi/spi.c
5

@alexandremalecot,

The example doesn’t raise a false-positive on my side so we definitely need a reproducer file to investigate what’s happening.

I sent you a private message. Can you share the scanner log in debug mode(-X) without the reproducer option.

Thanks,

6

@alexandremalecot,
Thanks for sharing the logs, you should set reproducer option to:
/home/alexsw/Documents/ADCS/Codes/atmega128-template/src/drivers/spi/spi.c

looking at the log I can see:

 use of undeclared identifier 'SPIF'
 use of undeclared identifier 'SPSR'
 use of undeclared identifier 'SPDR'

This explains the reason for the false-positive. If you look at the log there are a lot of macros(not just the one I mentioned) that are not found. Which will impact the analysis as a whole (it is not a problem in S995 but a configuration problem)

Is the definition of the macros included in spi.c(you have the same problem with other files too)? Can you look into why they aren’t defined? Also, share the reproducer privately it might give some hints.

7

Dear @Abbas,

We understand what you say. In fact, all 'SPIF" “SPDR” and other microcontroller peripheral registers macro definitions are defined in a header file specific to our microcontroller (iom128.h) provided by AVR library. We tried to explicitly include this file in our Makefile and nothing changed. Is there a way to specify sonar scanner where to find header files ? (for example, spi.c includes spi.h which includes iom128.h)

Thanks for your correction about the path for the reproducer, it succeeded. So attached you will find the reproducer output file (may be it still could be usefull for you)sonar-cfamily.reproducer (137.5 KB)

8

@alexandremalecot,

Can you share the build-wrapper.json file?

Thanks,

9

@Abbas,

Here you will find the build-wrapper-dump.json file, the build-wrapper.log and the sonar-cfamily.reproducer file to be sure they where created at the same compile/analysis stage.

10

@alexandremalecot,

Thanks a lot for providing all the logs. The problem is identified on our side: We don’t handle -mmcu option correctly which is leading to not including the file that contains the definitions of the macros. I created this ticket. I will get back to you soon with a fixed version.

Thanks,

1 Like
11

As confirmed by @alexandremalecot this issue is fixed, and going to be part of Cfamily 6.13.

1 Like
12

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