Cppcheck-1.71

Cppcheck-1.71 has been released

General changes:
- The deprecated options --suppressions and --exitcode-suppressions have been removed
- .hh and .hxx files are now treated as C++ files
- Improved documentation (readmes and manuals)
- Internal errors (for example syntax error) are now suppressable

Removed checks:
- Check for unnecessary qualification has been removed

Checking improvements:
- Support range-based for-loops (C++11)
- Better support for C++11 style initialization
- Better support for lambdas (C++11)
- Support digit separators (C++14)
- Added determination of the type of an expression (ValueType)
- Support case ranges (GCC extension)
- Improved AST generation and added validation
- Improved value flow analysis
- Improved checking for unitialized arrays
- Improved VarId assignment for member variables
- Rewrote checking of char variables
- Known variable simplification has been removed partially in favour of value flow analysis

GUI:
- Added library editor
- Improved display of inconclusive messages
- Added option to enforce parsing as C or C++ code
- Show file that included a header in details view
- Added "Recheck all files" button, "Recheck files " renamed to "Rechecked modified files"

Additionally, lots of false positives and bugs have been fixed and several existing checks have been improved.

[Ken Paulson]

The x64 build for windows seems to require WinRT DLLs so it won't run on Windows 7.

[Brett Rowbotham]

x64 build for 1.71 includes 32 bit build of cppcheckgui.exe and not 64 bit version.

[Simon Martin]

cppcheck GUI (x64) does not start under Win7 with error code 0xc0000007b.

Installing redistributable package for VS2015 did not fix this.

[Björn Blissing]

I found the reason for this error. The cppcheck installer pushes a 64bit DLL into the Windows/SysWOW64 folder. Uninstall the vc 2015 redistributables for x86, then go to the Windows/SysWOW64 forlder and manually delete the msvcp140.dll file. Then reinstall the vc 2015 redistributables. Then you should be able to reinstall/repair Visual Studio 2015.

[Greg Smith]

cpp check 1.71 kills VS 2015. I am kicking myself for allowing cppcheck to update VS2015. I am now struggling to get vs2015 repaired. If you are using VS2015 DO NOT DOWNLOAD cppcheck 1.71 until this issue is fixed.

[Björn Blissing]

See above post how to fix this error.

[Greg Smith]

Thank you for the information. Sadly, this does not fix the error. I still cannot get Visual Studio 2015 repaired after 3 weeks. If you know which files the 1.71 x64 cppcheck updated the system with, this would be MOST useful to know, so I can attempt to clean up the mess.

If you are saying that the x86 cppcheck installation updated the sysWOW64 folder (which should hold x86 dlls) with an x64 dll, then is it possible that the reverse happens when installing the x64 dlls? I am clutching at straws here...

[Björn Blissing]

I don't think that it would be a 32 bit DLL in the 64 bit directory, since Visual Studio is a 32 bit application.

I don't know what kind of error you are getting when reinstalling Visual Studio. But I got the fatal error when installing the "Team Explorer" component. I found a link on StackOverflow where a russian guy described how he was able to track down his problem using ProcessMonitor. I followed the same procedure and was able to find the offending DLL file that was preventing my install.

Start with downloading ProcessMonitor:
https://technet.microsoft.com/en-us/sysinternals/processmonitor.aspx

The process is as follows:
1. Uninstall Visual Studio
2. Start ProcessMonitor and start to capture logs.
3. Start the Visual Studio installation.
4. When the installation breaks down, stop the ProcessMonitor logging.
5. Look in your %TEMP% folder for the installation logs. You will find the point in time where the installation fails.
6. Go to that location in time in your ProcessMontor logs.
7. You will see that the VSIX installer tries to load diffrent DLL files. The pattern here is that it tries to find the file and then load it. If it can't find a DLL file the ProcessMonitor result will be NAME_NOT_FOUND. If it finds the file the result will be SUCCESS and the search for that DLL will terminate. But here is the key to finding the error (at least in my case): If it finds a file that it cannot use, the the result will still be SUCCESS, but since it cannot use it (due to being for the wrong architecture) the installer will try to find the file at a different location. It will look like this in the ProcessMonitor logs:

Hopefully you will be able to find the offending DLL file the same way. Then it is just a matter of uninstalling the redistributables, deleting this file and reinstalling the redistributables again.

Here is a link to the StackOverflow thread that got me going in the right direction:
http://stackoverflow.com/questions/33855177/multiple-errors-installing-visual-studio-2015-community-edition/33881460#33881460

[Greg Smith]

Well I tried all that and this does not appear to be the problem. It is very difficult to find the correct time for the failure. Some logs only give the time to an accuracy of 1 second, which is hopeless. The system Event viewer gives different times for the MSI installer fail to the logs, and the logs only give time to the nearest ms. There is no SysWOW64 error anywhere near any of these times. Looking through the ProcessMonitor there is no obvious failure point. There are repeated patterns (these look like walking through registry directory trees) that go on for many hundres of lines, and these do include horrible-looking errors (BUFFER_OVERRUN etc) but these do not seem to be fatal AFAICT).

[Björn Blissing]

I don't know what type of error you are getting. Could you share your error code for the install?

[Greg Smith]

I have managed to repair VS2015 by using msiinv to get a list of all msi install, then using msiexec -x {product code} on everything that was associated with VS2015... then reinstalling.

I think what happened was:

1) cppcheck copied the wrong DLLs.
2) Visual studio then collapsed on startup
3) I tried to repair VS, but I suspect that the repair process also depended on the damaged dlls, so this made matters worse.
4) I followed the advice above to remove the damaged dlls, but by now the VS installation was in a heap and normal installations were never going to work.

Anyhow, thank you for your input. Perhaps more checking should be done on new releases of cppcheck?