-
Analyzing the Quake III Arena GPL project
06.02.2012As you know, the id Software company has laid out source codes of many of their games. We already checked some of these projects earlier. This time we decided to analyze the Quake III Arena GPL source code. Analysis was performed with PVS-Studio 4.54. Read more -
Wade not in unknown waters. Part two
01.02.2012This time I want to speak on the 'printf' function. Everybody has heard of software vulnerabilities and that functions like 'printf' are outlaw. But it's one thing to know that you'd better not use these functions, and quite the other to understand why. In this article, I will describe two classic software vulnerabilities related to 'printf'. You won't become a hacker after that but perhaps you will have a fresh look at your code. You might create similar vulnerable functions in your project without knowing that. Read more -
How we managed the task of implementing trial mode in the PVS-Studio code analyzer
01.02.2012Choosing and changing the model of trial mode is one of the most relevant and widely discussed tasks for many software developers. It is easy to make a model for some programs and difficult for others. And some people are haunted by the question: "Have we made everything right?" The task of choosing a trial-model is relevant to us, PVS-Studio developers, as well. We decided to share some of our ideas regarding this subject and tell you about a new alternative we have invented. We hope that our arguments and some ideas will be helpful to other developers too. Read more -
Wade not in unknown waters. Part one
27.01.2012We decided to write several small posts on how C/C++ programmers play with fire without knowing it. The first post will be devoted to an attempt to explicitly call a constructor. Read more -
Tips on speeding up PVS-Studio
15.12.2011This note is obsolete. Please read "Tips on speeding up PVS-Studio" in documentation.. Read more -
On the good of automated filtering of identical messages
14.12.2011From the very beginning duplicates of messages in our analyzer PVS-Studio have been eliminated. For example, if a diagnostic message is generated for a code in an .h-file included into several .cpp-files, our tool will generate it only once. Some other analyzers don't do that and when they check .cpp-files, they show you messages every time on the same strings in .h-files. So it turns out that our analyzer generates fewer messages compared to such tools. But we had no chance to estimate how useful it is before. Now we've got such an occasion, and the results are really impressive. Read more -
"Please check this project too..."
13.12.2011We believe that the best way of promoting our static code analyzer PVS-Studio is using it to check famous open source projects (like Chromium, Clang, WinMerge and many others) and writing articles on the check results. This task is not so simple because, unfortunately, PVS-Studio is just a tool, not a magical program that can find all the errors itself. People often write to us asking to check this or that project and write an article on it. Read more -
Windows Error Reporting dialog
08.12.2011As with any other native Windows program, there exists a possibility of an unhandled exception being raised during the operation of PVS-Studio analyzer (the PVS-Studio.exe process in particular), this can be because of the call stack overflow for example. The Windows family operating systems starting with Windows Vista would generate a special emergency shutdown dialog in case of an unhandled exception allowing you to debug or close such crashing program. Read more -
About our VivaCore library
06.12.2011Those who are interested in the code analysis technology most likely have heard about our library VivaCore. It is this library our static analyzer PVS-Studio is based on. Earlier one could download the library from our site, but we have removed it recently and do not distribute it any more. Read more -
What amazes me while developing the static code analyzer
28.11.2011When developing any programmer tool, be it a compiler or a static analyzer, or anything else, it is naturally that programmers use test projects the tool is constantly ran on. For example, when developing our static analyzer, we run it on 70 real projects. It allows us to make sure that everything is alright and nothing is broken. Besides, when we develop new diagnostic rules, we can see the code fragments where the new errors have been detected, after running the tests. Everything is logical and obvious. But why did I entitle the post in that way?. Read more