non-standard compiler extension

[Calvin Chan]

Hi all

The description of CPPCheck supports non-standard compiler extension, but there is no further details on how to go about it. I am new to the utility and would like to try it out.

my code contains non-standard compiler stuff, e.g.

I declared an interrupt routine says keyIn as

@far @interrupt keyIn(void)
{
...
}

And also declaring MCU register variable, e.g.

uint8_t keyPattern @0x4000 ;

Here cppcheck points to the very 1st line of the file, as syntax error, (where the 1st line is a block of comments) and no way I knew that those @ stuffs further down into the file are the culprits.

Can anyone share any thought as to how to tackle those extensions?

Rgds

Calvin

[Daniel Marjamäki]

Good question.

As far as I know this non-standard variant is not supported right now.

We should handle it!

I intend to look at this soon. And hope you can try it out. We will release next Cppcheck version soon so hopefully it will work then.

[Daniel Marjamäki]

I am thinking about implementing a quick and simple fix now before the release. I would like that you test it.

What other keywords can there be after the @ more than "far" and "interrupt"?

A better fix will come later that will require that you configure the @ keywords.

[Calvin Chan]

Thank you for your quick reply.

The compiler that I am using is from cosmic software (http://www.cosmicsoftware.com/), for STM8 series MCU.

Besides the mentioned keywords, the complete list is

@far, @tiny, @near, @eeprom, @inline, @nostack, @stack, @packed, @vector, @builtin, @noprd, @nosvf, @svlreg and @interrupt

For bit addressing, like bit 3 of port B (address 0x10) can be

bool PB3 @0x10:3

or
volatile char PORTB @0x10;
bool PB3 @PORTB:3 ;

and declaring variable:
volatile char DDRB @0x05 ;

In general: can be @

:<bitnum>

Thank you.

Calvin

</bitnum>

[Daniel Marjamäki]

I implemented a simple fix: https://github.com/danmar/cppcheck/commit/49413b7d4cd6c8d33a12266c29a453ba6b371666

It would be great if you can try it out before the release!

[Calvin Chan]

oh, the last bits: In general: can be @ address : bitnum

Calvin

[Calvin Chan]

I am just a windows user and I have no idea on how to build your temp. release to make up the pre-release version.

Calvin

[Daniel Marjamäki]

I am just a windows user and I have no idea on how to build your temp. release to make up the pre-release version.

do you have mingw / cygwin / visual studio?

[Daniel Marjamäki]

compiling cppcheck is pretty straight forward if you have mingw / cygwin / visual studio.

but if you don't.. we might be able to upload a windows binary also that you can test. I assume you are running the 64-bit windows 1.85 installation?

[Daniel Marjamäki]

here is a windows binary that you can try: https://pkeus.de/~philipp/Temp/cppcheck.zip

[Calvin Chan]

bingo. This works so far. Thanks for support.

Calvin

[Calvin Chan]

Hi Daniel

Funny enough though. I have put all the headers into a sub-folder called header, and the source c files into a sub-folder called source, and the parent folder called temp.

cppcheck onto temp folder gives me no problem. But when I move all headers and sources just into temp folder and remove the sub-folders, all the sources give errors - at line 0, with summary of syntax error. As usual, the first part of the sources are many lines of comments before the actual code comes into.

see attached.

Any idea?

Calvin

[Daniel Marjamäki]

It is hard to say. Cppcheck does not search for headers recursively, you have to specify include paths explicitly, so apparently you get the syntaxError when the headers are found. When the headers are not found, cppcheck is happy. I assume you get the same syntaxError with "cppcheck -Itemp/headers temp". Maybe there is something in some header file that is confusing Cppcheck.

[Calvin Chan]

Hi Daniel

Your guess is confirmed. By adding the include path .\Header, all the c files become invalid. Somehow the header files get cppcheck confused. But there is no hint from cppcheck to pinpoint the problem. That makes this situation unsolvable.

Calvin

[Calvin Chan]

hi

The @ non-standard compiler extension is not quite done.

The array of characters at absolete address is one of the culprits.

Consider the following code snipplet:

volatile unsigned char ADC_DBR[20] @0x53e0; / data buffer registers /

void main(void)
{ unsigned char i = 100 ;
static unsigned char dummy ;

for(i = 0 ; i < 10 ; i++)
{}
}

Calvin

[Calvin Chan]

further to my previous message, one more culprit on @ is:

`#define INLINE_STATIC_FUNC @inline static
INLINE_STATIC_FUNC void softwareReset(void)
{
}

or alternatively

@inline static void softwareReset(void)
{
}
`

[Calvin Chan]

Hi

New release 1.86 has taken care of some of the non-standard compiler extension that I raised few days ago. Nevertheless, some are not addressed. e.g. the @inline keyword

@inline void dummyFunc(void)
{}

nor the absolute address on array declaration.
volatile unsigned char ADC_DBR[20] @0x53e0; // data buffer registers

Furthermore, I would expect the following sample code with different outcomes:

---

volatile unsigned char volatileRegister ;

void main(void)
{ unsigned char i = 100 ;

volatileRegister = 0x10 ;
volatileRegister = 0x20 ;
for(i = 0 ; i < 10 ; i++)
{
volatileRegister = 0x55 ;
}
}

---

1. cppcheck should give warning of the initialization of unsigned char i = 100, as it has not been used before i is re-initialized to 0 in the for loop
2. The warning of 2nd statement on assignment of volatileRegister = 0x20 should be silent as the re-assignment without 1st use of 1st assignment remain valid. Volatile registers may have different state changes upon responding to different sequence of assignments.

Calvin