Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #67880 > unrolled thread

What is easiest to use static C++ code analyser?

Back to article view | Back to comp.lang.c++

Contents

  What is easiest to use static C++ code analyser? Szyk Cech <szykcech@spoko.pl> - 2019-08-22 18:18 +0200
    Re: What is easiest to use static C++ code analyser? David Brown <david.brown@hesbynett.no> - 2019-08-22 20:04 +0200
    Re: What is easiest to use static C++ code analyser? Ian Collins <ian-news@hotmail.com> - 2019-08-23 08:42 +1200
    Re: What is easiest to use static C++ code analyser? legalize+jeeves@mail.xmission.com (Richard) - 2019-08-22 23:38 +0000
    Re: What is easiest to use static C++ code analyser? legalize+jeeves@mail.xmission.com (Richard) - 2019-08-22 23:38 +0000
    Re: What is easiest to use static C++ code analyser? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-08-25 06:09 +0000
    Re: What is easiest to use static C++ code analyser? Jens Kallup <jkallup@web.de> - 2019-08-28 15:57 +0200
      Re: What is easiest to use static C++ code analyser? legalize+jeeves@mail.xmission.com (Richard) - 2019-08-28 18:18 +0000
        Re: What is easiest to use static C++ code analyser? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-08-28 19:22 +0000
          Re: What is easiest to use static C++ code analyser? legalize+jeeves@mail.xmission.com (Richard) - 2019-08-28 20:00 +0000
            Re: What is easiest to use static C++ code analyser? David Brown <david.brown@hesbynett.no> - 2019-08-28 22:21 +0200
              Re: What is easiest to use static C++ code analyser? legalize+jeeves@mail.xmission.com (Richard) - 2019-09-03 20:17 +0000
                Re: What is easiest to use static C++ code analyser? David Brown <david.brown@hesbynett.no> - 2019-09-04 09:03 +0200
            Re: What is easiest to use static C++ code analyser? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-08-29 09:58 +0000
    Re: What is easiest to use static C++ code analyser? Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-04 10:44 +0200

#67880 — What is easiest to use static C++ code analyser?

Hello!

I want follow advises of great book: "Testen in Scrum-Projekten" by Tilo 
Linz. One of his advises which I consider easy to make is use static 
code analyser to check if programmers respect coding rules.

I am looking for C++ code analyser but I am interested with such tool 
for Java Script or Bash also.

I found great wiki page with list of most popular static code analysers:

https://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis

but I have no time to try all of them.
So maybe you have some experience with those tools if so:
Please answer me to question:

What is easiest to use static C++ code analyser?

Thak you in advance and best regards!
Szyk Cech

[toc] | [next] | [standalone]

#67884

On 22/08/2019 18:18, Szyk Cech wrote:
> Hello!
> 
> I want follow advises of great book: "Testen in Scrum-Projekten" by Tilo 
> Linz. One of his advises which I consider easy to make is use static 
> code analyser to check if programmers respect coding rules.
> 
> I am looking for C++ code analyser but I am interested with such tool 
> for Java Script or Bash also.
> 
> I found great wiki page with list of most popular static code analysers:
> 
> https://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis
> 
> but I have no time to try all of them.
> So maybe you have some experience with those tools if so:
> Please answer me to question:
> 
> What is easiest to use static C++ code analyser?
> 
> Thak you in advance and best regards!
> Szyk Cech

This will depend on your needs, and your budget.

Tools like Coverity, Klocwork and PVS-Studio are all powerful and well 
regarded, but can cost quite a lot of money.  This kind of tool will 
often run on a server and produce detailed reports.

At the other end of the scale, there are lots of free and open source 
analysers.  You can come a long way with the warnings found in good 
compilers like gcc, clang and MSVC, and can make good use of static 
assertions in your code.  (gcc and clang also have a selection of 
run-time checking sanitizers.)  Lightweight but helpful analysers like 
cppcheck can be integrated with an IDE - they don't spot as many errors, 
but what they do find, they identify as early as possible.

There are also lots of specialised tools for particular purposes, such 
as "Sparse" for spotting certain faults in the Linux kernel.

If you decide to use a tool beyond your compiler's warnings, there are a 
couple of things to watch out for.  One is that static analysers are 
often behind compilers in support for newer features and standards, and 
certainly for any compiler-specific extensions.  That may limit your 
coding styles.  The other is that they often need additional information 
in order to do more analysis - for many, this is done using comments in 
particular formats.  It is quite possible to end up with code where 
these special comments make it difficult to find and read the real code 
- if they distract from the readability of the code, they are 
counter-productive.

My recommendation is to start with the features provided in the compiler 
you are using - read the manual page for the warnings, and try them (not 
all will suit your programming style).  And use a good IDE with cppcheck 
or similar built in.  Only move on when you have outgrown these and are 
willing to spent some time and/or money on the matter.

[toc] | [prev] | [next] | [standalone]

#67889

On 23/08/2019 04:18, Szyk Cech wrote:
> Hello!
> 
> I want follow advises of great book: "Testen in Scrum-Projekten" by Tilo
> Linz. One of his advises which I consider easy to make is use static
> code analyser to check if programmers respect coding rules.
> 
> I am looking for C++ code analyser but I am interested with such tool
> for Java Script or Bash also.
> 
> I found great wiki page with list of most popular static code analysers:
> 
> https://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis
> 
> but I have no time to try all of them.
> So maybe you have some experience with those tools if so:
> Please answer me to question:
> 
> What is easiest to use static C++ code analyser?

We use two, Cppcheck and clang-tidy.

Cppcheck is reasonably fast, so we run it on every build. It spots a 
good number of problems, it categories issues as Error, Warning, Style, 
Performance, Portability and Information.  You can filter based on 
category or specific warning.

clang-tidy is much slower (we run it as a separate job) because it digs 
much deeper into the code and can follow control flow paths.  It has an 
extensive list of warnings, many of which can be automatically repaired. 
  See <http://clang.llvm.org/extra/clang-tidy/index.html#using-clang-tidy>

Both can be run in parallel, which speed things along if you have the 
hardware.

HTH,

-- 
Ian.

[toc] | [prev] | [next] | [standalone]

#67894

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

Szyk Cech <szykcech@spoko.pl> spake the secret code
<hfz7F.36165$Xs5.15669@fx06.am4> thusly:

>What is easiest to use static C++ code analyser?

Probably the easiest one to use is the one built into your C++
compiler.

Clang: <https://clang-analyzer.llvm.org/>
MSVC: /analyze
<https://docs.microsoft.com/en-us/cpp/build/reference/analyze-code-analysis?view=vs-2019>
gcc probably has something but nothing is turning up at the moment.

Outside of the compiler, I have used cppcheck and it's easy to run
outside of a build.  <http://cppcheck.sourceforge.net/>

The general advice is to run as many static analyzer tools as you can
because they all have strengths and weaknesses and they haven't yet
converged to have huge overlap, although there is some overlap.
-- 
"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>

[toc] | [prev] | [next] | [standalone]

#67895

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

ram@zedat.fu-berlin.de (Stefan Ram) spake the secret code
<code-analyzer-20190822191723@ram.dialup.fu-berlin.de> thusly:

>Szyk Cech <szykcech@spoko.pl> writes:
>>What is easiest to use static C++ code analyser?
>
>  Every static code analyzer is easy to use
>  (unless you want to use it under Windows).

Lies.
-- 
"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>

[toc] | [prev] | [next] | [standalone]

#67929

On Thu, 2019-08-22, Szyk Cech wrote:
> Hello!
>
> I want follow advises of great book: "Testen in Scrum-Projekten" by Tilo 
> Linz. One of his advises which I consider easy to make is use static 
> code analyser to check if programmers respect coding rules.
>
> I am looking for C++ code analyser but I am interested with such tool 
> for Java Script or Bash also.
>
> I found great wiki page with list of most popular static code analysers:
>
> https://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis
>
> but I have no time to try all of them.
> So maybe you have some experience with those tools if so:
> Please answer me to question:
>
> What is easiest to use static C++ code analyser?

The compiler itself -- the warnings which aren't enabled by default
but make sense anyway.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#67968

Hello,

if you would like to write your own text
analyze tool(s), I point you to have a look
over the compiler-compiler tool "bison",
and "flex", and yacc.

bison, flex, and yacc are available under
GPL licensed Open Source Code for most all
operating system's (Linux, Windows, MacOS).

Them the tool(s) can be download for C/C++,
Pascal/Delphi, Lazarus, etc...

Hope This Helps

Jens

[toc] | [prev] | [next] | [standalone]

#67971

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

Jens Kallup <jkallup@web.de> spake the secret code
<qk617q$72c$1@news.albasani.net> thusly:

>if you would like to write your own text
>analyze tool(s), I point you to have a look
>over the compiler-compiler tool "bison",
>and "flex", and yacc.

Sorry, but this is a HORRIBLE idea for parsing C++ code.

If you want to write your own code analysis tools, use the clang
libraries.
-- 
"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>

[toc] | [prev] | [next] | [standalone]

#67974

On Wed, 2019-08-28, Richard wrote:
> [Please do not mail me a copy of your followup]
>
> Jens Kallup <jkallup@web.de> spake the secret code
> <qk617q$72c$1@news.albasani.net> thusly:
>
>>if you would like to write your own text
>>analyze tool(s), I point you to have a look
>>over the compiler-compiler tool "bison",
>>and "flex", and yacc.
>
> Sorry, but this is a HORRIBLE idea for parsing C++ code.
>
> If you want to write your own code analysis tools, use the clang
> libraries.

There's also no indication whatsoever that the OP wanted to write the
tools himself -- he (understandably) didn't even want to evaluate the
ones which already are available to him.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#67976

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

Jorgen Grahn <grahn+nntp@snipabacken.se> spake the secret code
<slrnqmdl3j.cdo.grahn+nntp@frailea.sa.invalid> thusly:

>On Wed, 2019-08-28, Richard wrote:
>> [Please do not mail me a copy of your followup]
>>
>> Jens Kallup <jkallup@web.de> spake the secret code
>> <qk617q$72c$1@news.albasani.net> thusly:
>>
>>>if you would like to write your own text
>>>analyze tool(s), I point you to have a look
>>>over the compiler-compiler tool "bison",
>>>and "flex", and yacc.
>>
>> Sorry, but this is a HORRIBLE idea for parsing C++ code.
>>
>> If you want to write your own code analysis tools, use the clang
>> libraries.
>
>There's also no indication whatsoever that the OP wanted to write the
>tools himself -- he (understandably) didn't even want to evaluate the
>ones which already are available to him.

I agree, but suggesting that one use lex/yacc for parsing C++ is an
approach that many people have tried and failed.  It's a really awful
idea.  That suggestion should not be left out in the open
unchallenged.

This is particularly true when you can just use the clang libraries to
get a perfectly conforming C++20 parser that will just hand you an
AST.
-- 
"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>

[toc] | [prev] | [next] | [standalone]

#67977

On 28/08/2019 22:00, Richard wrote:
> [Please do not mail me a copy of your followup]
> 
> Jorgen Grahn <grahn+nntp@snipabacken.se> spake the secret code
> <slrnqmdl3j.cdo.grahn+nntp@frailea.sa.invalid> thusly:
> 
>> On Wed, 2019-08-28, Richard wrote:
>>> [Please do not mail me a copy of your followup]
>>>
>>> Jens Kallup <jkallup@web.de> spake the secret code
>>> <qk617q$72c$1@news.albasani.net> thusly:
>>>
>>>> if you would like to write your own text
>>>> analyze tool(s), I point you to have a look
>>>> over the compiler-compiler tool "bison",
>>>> and "flex", and yacc.
>>>
>>> Sorry, but this is a HORRIBLE idea for parsing C++ code.
>>>
>>> If you want to write your own code analysis tools, use the clang
>>> libraries.
>>
>> There's also no indication whatsoever that the OP wanted to write the
>> tools himself -- he (understandably) didn't even want to evaluate the
>> ones which already are available to him.
> 
> I agree, but suggesting that one use lex/yacc for parsing C++ is an
> approach that many people have tried and failed.  It's a really awful
> idea.  That suggestion should not be left out in the open
> unchallenged.
> 
> This is particularly true when you can just use the clang libraries to
> get a perfectly conforming C++20 parser that will just hand you an
> AST.
> 

Another option that would be interesting for static analysis is a gcc 
plugin, possibly written in a different language (Python is a reasonable 
choice for such tasks).

I can't tell you whether clang or gcc would be the best starting point 
for making your own static analysis tools, but I look at both of them 
/long/ before looking at lex/yacc.

[toc] | [prev] | [next] | [standalone]

#68182

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

David Brown <david.brown@hesbynett.no> spake the secret code
<qk6nnl$nh0$1@dont-email.me> thusly:

>On 28/08/2019 22:00, Richard wrote:
>> I agree, but suggesting that one use lex/yacc for parsing C++ is an
>> approach that many people have tried and failed.  It's a really awful
>> idea.  That suggestion should not be left out in the open
>> unchallenged.
>> 
>> This is particularly true when you can just use the clang libraries to
>> get a perfectly conforming C++20 parser that will just hand you an
>> AST.
>> 

>Another option that would be interesting for static analysis is a gcc 
>plugin, possibly written in a different language (Python is a reasonable 
>choice for such tasks).

Bwuahahahahaha!  That is hilarious.  Seriously.  I know they've
improved gcc at this point, but Stallman et al. have literally said
that they made the internal interface as painful as possible to put
into a library on purpose because they didn't want anyone doing that.

Clang was designed from the ground up to be used as a library.

>I can't tell you whether clang or gcc would be the best starting point 
>for making your own static analysis tools, but I look at both of them 
>/long/ before looking at lex/yacc.

Don't bother looking at lex/yacc because the context-sensitive nature
of many C++ constructs makes it impossible to use lex/yacc.

Don't waste your time with GCC because it isn't designed to be used
this way.

Go straight to clang because that's what it's been designed for.
-- 
"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>

[toc] | [prev] | [next] | [standalone]

#68202

On 03/09/2019 22:17, Richard wrote:
> [Please do not mail me a copy of your followup]
> 
> David Brown <david.brown@hesbynett.no> spake the secret code
> <qk6nnl$nh0$1@dont-email.me> thusly:
> 
>> On 28/08/2019 22:00, Richard wrote:
>>> I agree, but suggesting that one use lex/yacc for parsing C++ is an
>>> approach that many people have tried and failed.  It's a really awful
>>> idea.  That suggestion should not be left out in the open
>>> unchallenged.
>>>
>>> This is particularly true when you can just use the clang libraries to
>>> get a perfectly conforming C++20 parser that will just hand you an
>>> AST.
>>>
> 
>> Another option that would be interesting for static analysis is a gcc 
>> plugin, possibly written in a different language (Python is a reasonable 
>> choice for such tasks).
> 
> Bwuahahahahaha!  That is hilarious.  Seriously.  I know they've
> improved gcc at this point, but Stallman et al. have literally said
> that they made the internal interface as painful as possible to put
> into a library on purpose because they didn't want anyone doing that.
> 

That was certainly true.  But it is a long time - a very long time -
since Stallman and others with that attitude have ruled gcc.  There is
no doubt that Stallman specifically wanted strong ties between different
parts of the code in gcc, to make it as difficult as possible to split
it up and mix the gcc front ends with commercial or closed backends, or
vice versa.  However, as the project grew, with many more people
involved, many front ends, and many back ends, it got steadily cleaner
separation and more modularisation.  And with gcc 4.5, nearly 10 years
ago (IIRC), it got plugin support.

One of the big influences and motivations for gcc plugins is the
competitive / cooperative relationship with llvm/clang.  The two
projects push each other forward, which is great for users of either
tool suite.

RMS may not like the fact that gcc has plugins, with the risk that has
of mixing closed source software with gcc, but there is no doubt that
gcc supports plugins and these are used, amongst other things, for
additional static analysis.

> Clang was designed from the ground up to be used as a library.
> 

True.

>> I can't tell you whether clang or gcc would be the best starting point 
>> for making your own static analysis tools, but I look at both of them 
>> /long/ before looking at lex/yacc.
> 
> Don't bother looking at lex/yacc because the context-sensitive nature
> of many C++ constructs makes it impossible to use lex/yacc.
> 

True.

> Don't waste your time with GCC because it isn't designed to be used
> this way.

Unless you are stuck a decade behind the times, /do/ look at gcc, and
especially the existing plugin libraries, if you want to make your own
static analysis.  And look at clang.  Compare their approaches, compare
the documentation, websites, blogs, tutorials, third-party code,
examples and other information.  Then figure out what is going to make
sense for the kind of tool you want to make and use.

My guess - and it is only a guess - is that clang is going to be the
best base if you want to write a large-scale checker and you want high
speed for analysing large code bases.  And gcc with the Python or Melt
(Lisp) plugins are going to be good for small-scale checks written in
higher level languages.

> 
> Go straight to clang because that's what it's been designed for.
> 

[toc] | [prev] | [next] | [standalone]

#67992

On Wed, 2019-08-28, Richard wrote:
> [Please do not mail me a copy of your followup]
>
> Jorgen Grahn <grahn+nntp@snipabacken.se> spake the secret code
> <slrnqmdl3j.cdo.grahn+nntp@frailea.sa.invalid> thusly:
>
>>On Wed, 2019-08-28, Richard wrote:
>>> [Please do not mail me a copy of your followup]
>>>
>>> Jens Kallup <jkallup@web.de> spake the secret code
>>> <qk617q$72c$1@news.albasani.net> thusly:
>>>
>>>>if you would like to write your own text
>>>>analyze tool(s), I point you to have a look
>>>>over the compiler-compiler tool "bison",
>>>>and "flex", and yacc.
>>>
>>> Sorry, but this is a HORRIBLE idea for parsing C++ code.
>>>
>>> If you want to write your own code analysis tools, use the clang
>>> libraries.
>>
>>There's also no indication whatsoever that the OP wanted to write the
>>tools himself -- he (understandably) didn't even want to evaluate the
>>ones which already are available to him.
>
> I agree, but suggesting that one use lex/yacc for parsing C++ is an
> approach that many people have tried and failed.  It's a really awful
> idea.  That suggestion should not be left out in the open
> unchallenged.

Yes, that was also worth pointing out, for other readers.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#68208

The best code analyzer is: printing the code out, having a bath
with the printouts in the hand or lying in the bad with the code
in the hand and a purring cat beside.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.c++

csiph-web