Daniel Marjamäki

I have moved the repositories cppcheck, simplecpp and cppcheck-htdocs to https://github.com/cppcheck-opensource

I would like that the --xml-version=3 report contains a list of files. All source and header files that has been used in the analysis. And I would prefer to write the SHA-256 hash for each file. With this information it will be possible to verify later if a certain xml report was generated when cppcheck checked certain files with specific contents or not. I have looked up https://github.com/okdshin/PicoSHA2 it looks acceptable to me.. What is your opinions? Do you feel it's a nice feature for open...

Hi, as far as I remember misra.py covers amendments 1 & 2. But not amendments 3 & 4. I.e. rules 1.4 and 1.5 are missing. We have not actively removed or crippled the functionality in misra.py. When it said that MISRA C:2012 support was complete in misra.py it meant that we had implemented checkers for all rules. It did not mean that each checker would catch all violations. We have made lots of improvements in the checkers in Cppcheck Premium it has substantially better coverage of many rules. I am...

Hi, as far as I remember misra.py covers amendments 1 & 2. But not amendments 3 & 4. I.e. rules 1.4 and 1.5 are missing. We have not actively removed or crippled the functionality in misra.py. When it said that MISRA C:2012 support was complete it meant that we had implemented checkers for all rules. It did not mean that each checker would catch all violations. We have made lots of improvements in the checkers in Cppcheck Premium it has substantially better coverage of many rules. I am not against...

I am thinking about moving the open source cppcheck-related repos. my idea was to move from danmar/cppcheck to some cppcheck/cppcheck path. however owner "cppcheck" seems to be taken already. Anyway the repos will be owned by an organisation instead.. https://docs.github.com/en/repositories/creating-and-managing-repositories/transferring-a-repository before I do it.. does anybode envision some particular problems.

It is much cleaner to construct the variable with the correct type instead of using a static_cast, +1 I also see such somewhat related code now and then: auto s = std::string{"hello"};

so as I read it we think that example 2 and example 3 are OK. I believe that example 1 is discussible. There may be situations where auto is preferable and then there are situations where it would be better to remove the cast and not use auto. Imho, the downsides of the auto+cast is that it's extra code and it can hide compiler warnings that may point out real bugs.

It is much cleaner to construct the variable with the correct type instead of using a static_cast, +1 casts can hide compiler warnings about real bugs. I also see such somewhat related code now and then: auto s = std::string{"hello"};