False Syntax error notices

[Chris Ratliff]

I ran through my source repository with cppCheck and a few files reported having a syntax error on line 0. Every source file in the repository starts with the same comment header:

//*****************************************************************************
//

The error is only reported in a few files, but every file starts with this on line 0.

Two smaller issues:
If cppCheck knows there is a syntax error why can't it ouptut what it believes that error to be?

The documentaion I found, http://cppcheck.sourceforge.net/manual.pdf mentions explicitly that cppCheck does not check for syntax errors as this is handled by the compiler. This should be updated to reflect the feature if it is working.

[Alexander Mai]

It's not a goal of cppcheck to find syntax errors - it assumes it is running on valid code. However when cppcheck does not understand the syntax it may throw this error. Also it stops analysis on that file (to avoid false positive or internal errors).

[Seaware]

We had this problem too. We found the message was for line 0 even though our "syntax error" was on line 30. I say "syntax error" in quotes because the issue was an IAR linker directive that the compiler accepted just fine, but wasn't standard C. Once we found another way to express the syntax, the line 0 error went away.

[Sean Michael McGhee]

I have encountered the faux syntax error as well and know what it's complaining about. In my case it's a cast:

((Thread^)m_RequestPool[m_ThreadCount])->Name = "Dragon Client " + caller;

it doesn't like the "Thread^)" part of the line.

Whereas it's prudent to want to stop false positives, it might be nice to have a way to have it ignore them since it is assuming to begin with that it's looking at valid code. I can't keep commenting out lines like this when most of my code contains them. Otherwise the tool is useless.

[Daniel Marjamäki]

Well (Thread^) is not a C/C++ cast. Is it objective/managed C++ or something? Cppcheck does not know about such casts and therefore warns.

If it is objective/managed C/C++ I am afraid that is out of scope for Cppcheck. I am no expert in these dialects but I fear there are a number of concepts that Cppcheck would need to understand.. it's not just these casts.

[Sean Michael McGhee]

Thanks. Well, I'll try something else then. Cheers!

[F. Cenedese]

On 21 Aug 2020 17:34, "Daniel Marjamäki" wrote:

Well |(Thread^)| is not a C/C++ cast. Is it objective/managed C++ or
something? Cppcheck does not know about such casts and therefore warns.

If it is objective/managed C/C++ I am afraid that is out of scope for
Cppcheck. I am no expert in these dialects but I fear there are a number
of concepts that Cppcheck would need to understand.. it's not just these
casts.

Just thinking: Doxygen allows to define filters where the examined
source files are first filtered and can be adjusted to "normal" code.
It can go even as far as converting a completely unknown language
or format into another format that Doxygen understands.

Maybe if Cppcheck could first apply a custom filter script then
such cases could be turned into valid C++. I think that wouldn't
need much effort (another program parameter, calling the filter
script with each input file, reading in the generated output,
then continue with normal processing as before).

Just an idea. I only use it cor C++.

bye Fabi

[Daniel Marjamäki]

I am not strongly against that idea in theory..

However a user could also easily do such conversions before he runs cppcheck in some temporary path.