OK, so I've fixed three of the bugs, not sure about how/if to fix the others.

http://www.postgresql.org/message-id/CAASwCXe2rQX66Wzw10KMEh... http://www.postgresql.org/message-id/CAASwCXfgFsMt31c1srj=Fs... http://www.postgresql.org/message-id/CAASwCXeKeVpJi03mjzdY6A...

This was a very interesting article for me. I find it amazing how even in a codebase such as PostgreSQL's, which is very mature and values reliability, data integrity, and correctness, errors like these could be found by a static code analysis tool.

Some of the rules seem brilliant, like successive assignment detection.

Interesting

About the memset bug, I wonder if this couldn't be solved by some kind of compiler directive in the function signature saying "you can't remove this" (or something to that effect)

For gcc, there is this (to be used after the memset() call):

  asm volatile("" : : : "memory");

(see https://en.wikipedia.org/wiki/Memory_ordering#Memory_barrier...)

Thats why C11 has memset_s. http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1381.pdf

This is a good writeup, thanks

You don't need such a _compiler_ directive. The compiler can only optimize the call away because it can assume that std::memset does what the standard proscribes.

Whenever you call an external function that is not in the standard library, the compiler can't know what it does and, hence, can't optimize it away.

The linker, on the other hand, might do across-library optimizations that lead to it removing the call. So, at worst, you need a linker directive.

Also, I am not sure you want this tagged to the function signature. There may be cases where optimizing the call away is perfectly valid.

Well he mentions RtlSecureZeroMemory(), which must be a Windows thing, but clearly all compilers need some methods of dealing with this thats easy to do and can't be optimised away.

I wish they would do a MySQL check so we can compare it with this one.

Interesting

Disclaimer: I didn't check the code

But maybe the sizeof(buf) is right? - if you want the size of the pointer (maybe if you're using wide chars?)

Especially since it's an 'Error_message_buf' type

EDIT: probably not, I'm thinking of sizeof(buf[0]), sizeof(buf) makes even less sense, it's a bug unless someone has a very good reason for it

Amazing that the tool detects collections of similar blocks, it's not wrong per se, but it's a common source of copy-paste bugs.

if they dont put the price online, it must be very expensive

I don't know this tool but I imagine they want to make very individual prices. They probably want to know who is interested in buying this tool before they tell you a price. Also they probably have lot's of (complicated) pricing models in mind and it would be too complicated to describe all the possibilities on the website.

I have worked in a similar project myself. We developed a very specialized tool for developers. Our boss decided that he did not want to mention prices on the website at first. Once we did some people complained publicly about the price although we invested months of development and the tool was pretty neat...

In general I think it makes more sense to tell the prices upfront and try to come up with a simple price model even if it means making compromises. You can always have something like this on your website: "If you think you do not fit in any price tier please contact us to find an individual price. The prices listed are meant to show what we have in mind for the general customers."

I would love to know the reason why some people think not having prices is a good idea. Care to elaborate?

Nutshell: Some clients expect a product with service and support behind it, and they expect to pay for it. In fact, if your price doesn't obviously include support you will be overlooked for not charging enough. Too low is not a plausible price. They will have to be charged more than a startup that wants to apply the tool using their own manpower and but for serious bugs, will provide most of their own tech support.

PVS-Studio. Prices Dropping - http://www.viva64.com/en/b/0217/

You can write us at support@viva64.com and receive individual price for your team.

Let's put that another way: if you have enough salesmen to operate smoothly given a high-touch sales process... your product must, on average, be very expensive.

We don't have sales. We are developers.

You guys are ruthless! Please see my earlier comment about different types of customers vs. pricing models. If you are a lean startup, variable pricing can work to your advantage. But it's certainly different than buying from commodity vendors who compete only on price.

I don't think people think that it's objectively too expensive, considering the time it saves for developers.

But without any pricing guidelines published on http://www.viva64.com/en/order/, it could be anywhere between $1k to $100k, and people assume without even asking that they cannot afford it.

I have a hard time differentiating between ruthlessness and contrarianism these days.

You act as if there is a difference. These things mean the same thing.

And what do you mean by "hard time?" How can a temporal concept take on attributes of a physical surface?

beep boop

Is it more expensive than the potential downside if you run into one of these bugs? Sure, living dangerously allows you to avoid paying any up-front costs (e.g., the price of this tool), but on the other hand, without a tool like this it's hard to even tell what the probability of failure is or how much it'll cost you if something does fail.

Viva64 is not cheap, but it looks like an extremely solid tool; I'd imagine that for anyone with a reasonably large C/C++ codebase, it'd quickly pay for itself by offsetting time developers would otherwise spend troubleshooting, tracking down, and fixing bugs.

Probably cheaper than the shitty imitations of what this tool does in the web dev industry.

Talking to a vendor a couple months ago, they wanted $15k for a tool whose bug/security problem coverage they couldn't enumerate.