PVS-Studio Blog

Yes, PVS-Studio is very good and useful for avoiding bugs.

No, companies don't really care about avoiding bugs. No one at Samsung will risk delaying the release of the next plastic crap product by fixing any problems. Why would they? Defects will even encourage customers to buy a new device because they are used to getting no bug fix updates. This is the worst possible company for Viva64 to go to.

It seems like C++ developers either don't give a shit about code quality or they do, and don't make many mistakes anymore. Either way there is little demand for a static analyzer. It won't get easier for Viva64 in the future. A few years ago, Compilers and IDEs started providing similar warnings as PVS-Studio, although not quite as sophisticated yet. Code-level testing begins to be a thing in proprietary software. Clang offers valgrind-like sanitizers for different classes of bugs that even PVS-Studio cannot detect.

TIL that Viva64 has over 20 employees. The passive-aggressive blog posts always made it look like one or two people running PVS-Studio as a side project or so. I read those posts regularly, but I don't remember them announcing any new features or improvements in PVS-Studio itself. Why do I have to pay annually if they don't spend the money on improving the product?

I am not even sure if PVS-Studio is worth the money. They don't have prices on the web site and defend their business decisions in the FAQ (https://www.viva64.com/en/order-faq/) in a very unprofessional…

Having done similar work for Chrome, I can attest to the fact that large code bases are full of errors.

If you're not on Windows, using both gcc's -Wall and -Wextra along with Clang in the same way is a good start. (Here's a post with more details: http://neugierig.org/software/chromium/notes/2011/01/clang.html .) The Clang static analyzer wasn't very useful at the time I tried it because it didn't analyze C++ code. Valgrind also finds a lot but it is harder to be diligent about fixing.

The PVS Studio guy (mentioned in Carmack's post) ran our code through it as well and also found a number of bugs, as described in a few posts: http://www.viva64.com/en/a/0074/ http://www.viva64.com/en/b/0113/ . (As Carmack supposed, they also claimed the Chrome code was some of the best they'd seen. But it's more likely they were being truthful in both cases.)

They've also ran the Chrome code through Coverity, but I haven't been involved in fixing those bugs so I don't know how useful it was. Searching the bug tracker for [coverity] turns up a handful of bugs, but it's possible more are hidden for security reasons.

I just love this one: http://www.viva64.com/en/examples/V504/

void GlyphComboBox::update(SPFont* spfont)
{
if (!spfont) return // <=
//TODO: figure out why do we need to append("")
// before clearing items properly...

//Gtk is refusing to clear the combobox
//when I comment out this line
this->append("");
this->remove_all();
}

Gee, why do you need the dummy append? It's because you put in so many TODO comments that you concealed the missing semicolon that you otherwise might have found ...

This is arguably not a bug; the developer tested the code, massaged it into working as expected, using what look like well-defined constructs, and documented their surprise at certain aspects of the code, leaving this issue easy to find with a grep for TODO.

On another note, what is surprising here is that they didn't catch it with their compiler. Look, the function returns void. GCC has a diagnostic for this, something like "return with expression in a function returning void". I think that still kicks in even if that expression has void type.

>The title is very misleading.

I agree the title originally as submitted[1] is not helpful. When the author submitted[2] it to Intel DZ, he re-used the same vague title as the original PVS-Studio article from April 2016: http://www.viva64.com/en/b/0391/

HN admins already edit titles with [YEAR] to signify an old article. In the same vein, I do wish the admins (or the original submitters to save the admins the effort) went even further and exercised editorial judgement to add [NON-CUTE SUBTITLE] to negate the effects of cute-but-meaningless titles.

In this case, there would be a "[C/C++ refactoring tips]" like you suggested appended to the end of the title.

[1] original submitted HN title: "The Ultimate Question of Programming, Refactoring, and Everything"

[2] https://software.intel.com/en-us/articles/how-to-contribute-to-intel-developer-zone

So far I'm impressed by every demonstration of PVS Studio that gets linked here and I love the developer's way of using open source projects for demonstrations (and thereby improving these projects). Great job.

Unfortunately the software seems to have no single developer license (only 'Team' and 'Site') and you have to write them a mail to even get a quote [1]?

In other words: Awesome tool, completely unavailable and out of reach for me.

Are there any somewhat comparable tools in the C# world that you use in your projects, apart from StyleCop/FxCop?

1: http://www.viva64.com/en/order/ - "Please write us from your corporate e-mail address for details on PVS-Studio prices. Specify information about your company and the type of license you would like to purchase (see the table below)."

One thing article does not mention is the false positives. Filter helps only partially, i'm still left with hundreds of false positives. PVS-Studio considers false-positives as natural part of the progress. A total turn-off me.
Cppcheck does very well in that regard, i only have 2 false positives with cppcheck. Best part is they are considered bugs by cppcheck team.
Also wonder about the opposite, errors that have been caught by cppcheck but ignored by PVS-Studio. They do exist.
http://www.viva64.com/en/b/0149/

My points are:
- Every c++ project should use cppcecheck since it has almost no noise.
- PVS-Studio if you have a dedicated analyst in your team and able to pony up $10k per year.