How to Improve Visual C++ 2017 Libraries Using PVS-Studio

[Andrey Karpov]

The title of this article is a hint for the Visual Studio developers that they could benefit from the use of PVS-Studio static code analyzer. The article discusses the analysis results of the libraries in the recent Visual C++ 2017 release and gives advice on how to improve them and eliminate the bugs found. Read on to find out how the developers of Visual C++ Libraries shoot themselves in the foot: it's going to be interesting and informative.

Article: https://www.viva64.com/en/b/0502/

[Rick C. Hodgin]

On Tuesday, May 2, 2017 at 8:28:49 AM UTC-4, Andrey Karpov wrote:
> The title of this article is a hint for the Visual Studio developers that they could benefit from the use of PVS-Studio static code analyzer. The article discusses the analysis results of the libraries in the recent Visual C++ 2017 release and gives advice on how to improve them and eliminate the bugs found. Read on to find out how the developers of Visual C++ Libraries shoot themselves in the foot: it's going to be interesting and informative.
>
> Article: https://www.viva64.com/en/b/0502/

Are you here selling your product? Are you hoping we'll go and buy
your tool from this advertisement post?

How much does your product cost? I go to the Buy page and I don't
see a price, but only a "Contact us" reference. Do you sell it for
different prices to different people?

How much of a gain will I get by using it? Can you guarantee it will
take away my rheumatism and cure my arthritis? Will it help to regrow
the hair I've lost?

Or ... what does it do for me that makes it worth my approaching you
through the "Contact us" link and inquiring as to the price?

Thank you,
Rick C. Hodgin

[Andrey Karpov]

> Are you here selling your product? Are you hoping we'll go and buy
> your tool from this advertisement post?
>
> How much does your product cost? I go to the Buy page and I don't
> see a price, but only a "Contact us" reference. Do you sell it for
> different prices to different people?
>
> How much of a gain will I get by using it? Can you guarantee it will
> take away my rheumatism and cure my arthritis? Will it help to regrow
> the hair I've lost?
>
> Or ... what does it do for me that makes it worth my approaching you
> through the "Contact us" link and inquiring as to the price?

I spread the word about static analysis in general and about PVS-Studio analyzer in particular. My mission is to show that static analyzers may be useful. That is what I am doing, but you would probably agree that it would be strange to do it using a different tool as an example, without speaking about PVS-Studio.

We have no license to individual developers. An article on this topic: https://www.viva64.com/en/b/0320/

We sell the analyzer to the development teams and the price request is a common practice. For example, Coverity does the same thing. We can provide the prices in various currencies and for teams of various sizes. Therefore, the question of licensing is always discussed by e-mail.

[Richard]

[Please do not mail me a copy of your followup]

Andrey Karpov <karpo...@gmail.com> spake the secret code
<c2ea904f-4049-40a9...@googlegroups.com> thusly:

>I spread the word about static analysis in general and about PVS-Studio

>analyzer in particular. [...]

Please do continue spreading the word!

Static analysis tools are wonderful additions to the C++ developer's
toolbox. Use as many of them as you can is my consistent advice.
Each tool has it's own strengths and weaknesses and they don't always
turn up the same issues.

To get your feet wet you can try some free tools:

Adding Static Analysis to Your C++ GitHub Repository
<https://legalizeadulthood.wordpress.com/2014/12/07/adding-static-analysis-to-your-c-github-repository/>

Visual Studio 2017 Community Edition includes improved static analysis
including experimental support for the C++ Core Guidelines.
<http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines>

I ran this on one of our production code bases (3D subdivision surface
modeler, ~700 Klocs) and it found a gaggle of potential NULL
dereference errors. I'm in the process of fixing those. Finding
these through manual testing would have been prohibitively tedious and
exhausting.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Terminals Wiki <http://terminals-wiki.org>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>

[Ian Collins]

On 05/ 4/17 09:50 AM, Richard wrote:
>
> Visual Studio 2017 Community Edition includes improved static analysis
> including experimental support for the C++ Core Guidelines.
> <http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines>
>
> I ran this on one of our production code bases (3D subdivision surface
> modeler, ~700 Klocs) and it found a gaggle of potential NULL
> dereference errors. I'm in the process of fixing those. Finding
> these through manual testing would have been prohibitively tedious and
> exhausting.

You use naked pointers, shocking! :)

--
Ian

[Richard]

[Please do not mail me a copy of your followup]

Ian Collins <ian-...@hotmail.com> spake the secret code
<emvp0p...@mid.individual.net> thusly:

The code base is 25 years old in some places. It depends on
commercial libraries that are 15+ years old.

There's nothing wrong with naked pointers per se. The problem is when
they are both used to express access as well as ownership. The C++
Core Guidelines Support Library uses the owner<> template to decorate
a pointer as expressing the concept of ownership:
<http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#gslview-views>

"The "raw-pointer" notation (e.g. int*) is assumed to have
its most common meaning; that is, a pointer points to an object,
but does not own it. Owners should be converted to resource
handles (e.g., unique_ptr or vector<T>) or marked owner<T*>."

For this code base, it will be a while before I could use unique_ptr<>
because of the legacy build environment. Modernization is on the road
map, but has other organizational dependencies that aren't as easy to
fix as committing to the repository :).

For those of you who work in organizations larger than yourself, this
is probably a familiar story.

When I was at Fusion-io, we had the difficulty that we couldn't switch
to C++11 because the enterprise linux distributions didn't come with a
modern compiler by default. Yes, this was a solvable problem, but
involved company-wide concerns beyond our team and as a result, it
didn't move forward as rapidly as we would have liked. RHEL7 uses gcc
4.8.x by default and at the time I was there, I don't think it was
even that far along. <https://access.redhat.com/solutions/19458>
SUSE had a similar problem. I understand why they are laggy, but it
means you have to go out of your way on these linux distros to build
and redist applications using modern C++.

[Florian Weimer]

* Richard:

> When I was at Fusion-io, we had the difficulty that we couldn't switch
> to C++11 because the enterprise linux distributions didn't come with a
> modern compiler by default. Yes, this was a solvable problem, but
> involved company-wide concerns beyond our team and as a result, it
> didn't move forward as rapidly as we would have liked. RHEL7 uses gcc
> 4.8.x by default and at the time I was there, I don't think it was
> even that far along. <https://access.redhat.com/solutions/19458>
> SUSE had a similar problem. I understand why they are laggy, but it
> means you have to go out of your way on these linux distros to build
> and redist applications using modern C++.

Note that the major distributions now offer supported compilers which
cover newer C++ versions (Toolchain Module for SUSE and Developer
Toolset for Red Hat). So tool availability should be less of a
concern these days.

[Richard]

[Please do not mail me a copy of your followup]

Florian Weimer <f...@deneb.enyo.de> spake the secret code
<877evb3...@mid.deneb.enyo.de> thusly:

Good news! Thanks for that.