Daniel Marjamäki

> Relative paths are bad idea. well this is how Cppcheck works in Windows. And the cppcheck premium also uses a relative path.

> Not closing this yet as the additional concerns still need to be tracked in tickets. good :+1:

As far as I understand an alternative is to name the platform file "win32A.xml" and "win32W.xml" instead. I do not know if users prefer win32A or win32a.

If we internally say win32A or win32a I don't care at all. I don't feel sure it's necessary to break the user interface. I mean this does not cause any...

Here is our list of "client and plugins" from our webpage: Buildbot - [integrated](https://docs.buildbot.net/latest/manual/configuration/steps/cppcheck.html) CLion - [Cppcheck plugin](https://plugins.jetbrains.com/plugin/8143) Code::Blocks - integrated CodeDX (software assurance tool) - [integrated](http://codedx.com/code-dx-standard/) CodeLite - integrated...

Can you show some results? I fear that 99% of bugs exposed will be for passing garbage data to cppcheck. Cppcheck is not very robust for garbage input. I think...

Do I understand it correctly that you suspect there will not be garbage code? Only compilable code will be tested? > I ran it for around 10 minutes and no...

> No, it will produce garbage code. so whats the plan when there is a crash for non-compilable code. how do we tell oss-fuzz that we don't care about that...

wild idea; could you run `gcc -fsyntax-only` or some lightweight syntax checker before passing the code to cppcheck?

> That said, a bug triggerable by garbage input doesn't imply it's not triggerable by syntax-valid input. Yes that is true.