What we had to test and
what we learnt during the
creation of the Linux version
of PVS-Studio
Svyatoslav Razmyslov
Evgeniy Ryzhkov
PVS-Studio
www.viva64.com
Who needs static code analysis?
• Beginners
• «Hindu programmers»
• Bad programmers
MySQL (C++)
A lot of similar strings.
Everything should be
fine.
static int rr_cmp(uchar *a, uchar *b)
{
if (a[0] != b[0])
return (int)a[0] - (int)b[0];
if (a[1] != b[1])
return (int)a[1] - (int)b[1];
if (a[2] != b[2])
return (int)a[2] - (int)b[2];
if (a[3] != b[3])
return (int)a[3] - (int)b[3];
if (a[4] != b[4])
return (int)a[4] - (int)b[4];
if (a[5] != b[5])
return (int)a[1] - (int)b[5];
if (a[6] != b[6])
return (int)a[6] - (int)b[6];
return (int)a[7] - (int)b[7];
}
CryEngine 3 SDK (C++)
inline bool operator != (const SEfResTexture &m) const
{
if (stricmp(m_Name.c_str(), m_Name.c_str()) != 0 ||
m_TexFlags != m.m_TexFlags ||
m_bUTile != m.m_bUTile ||
.....
m_Sampler != m.m_Sampler)
return true;
return false;
}
Linux (C) kernel
static int tc_ctl_action(struct sk_buff *skb,
struct nlmsghdr *n)
{
struct net *net = sock_net(skb->sk);
struct nlattr *tca[TCA_ACT_MAX + 1];
u32 portid = skb ? NETLINK_CB(skb).portid : 0;
....
}
The function
got an
argument:
Dereferencing
Oops, it should be checked too.
These bugs have ALWAYS been there.
Taken from Cfront compiler, year 1985:
Pexpr expr::typ(Ptable tbl)
{
....
Pclass cl;
....
cl = (Pclass) nn->tp;
cl->permanent=1;
if (cl == 0) error('i',"%k %s'sT missing",CLASS,s);
....
}
Nothing has changed for the past 30
years. Modern Clang compiler:
Instruction *InstCombiner::visitGetElementPtrInst(....) {
....
Value *StrippedPtr = PtrOp->stripPointerCasts();
PointerType *StrippedPtrTy =
dyn_cast<PointerType>(StrippedPtr->getType());
if (!StrippedPtr)
return 0;
....
}
Static analysis methodology
 Automated code review
 Regular checks
 The human factor is avoided (it is lowered, to be exact).
 Specialized tools. The more the better.
But maybe not.
What did the PVS-Studio users wanted
from the Linux version of PVS-Studio?
 Command line utility;
“We don’t need integration with IDE!”
 We don’t need an installer
"We will set everything ourselves!»
 We don’t need the documentation
“We’ll run the program ourselves”
The first build and support
 The executable file is not a product
 Porting the code is only a small part of the work
 You cannot make conclusions without full-fledged
testing - comparison of testing on Windows and Linux
Myth of knowing build scripts
 Not all developers are completely familiar with the build
system
 People need some way of getting to know the product
without integrating and setting up
 This method should be quite reliable to leave a good
impression from the product
Support of multiple Linux
distributions
The choice of the monitoring technology
 (-) Clang scan-build
 (+) strace
 (+) JSON Compilation Database
 (+/-) RD_PRELOAD
Innumerable non-standard extensions of
GCC compilers
Closed testing of a Beta version
Episode 1
 The executable file of the analyzer with the setup script
 Online documentation
 Several different ways to analyze without the integration
Closed testing of a Beta version
Episode 2
 Support of non-standard compiler extensions
 Dealing with false alarms
 Creating Deb/Rpm packages
 Small tasks concerning the analyzer and the
documentation
Closed testing of a Beta version
Episode 3
 We decided not to use the config files for a quick check
 Improved work with the log of the strace utilitiy
 Work on the DEB/RPM packages
 Other tasks concerning the analyzer and the documentation
Closed testing of a Beta version
Episode 4
(Release Candidate)
 Heading towards the integration into large projects
 Implementation of various user requests
 Our own repositories for DEB/RPM packages*
Integration into Makefile/Makefile.am
.cpp.o:
$(CXX) $(CFLAGS) $(DFLAGS) $(INCLUDES) $< -o $@
pvs-studio --cfg $(CFG_PATH) --source-file $< --language C++
--cl-params $(CFLAGS) $(DFLAGS) $(INCLUDES) $<
 Details in the analyzer setup
 Incremental analysis
 Parallelization of the analysis on the build system level
 Other pluses of the build system
Integration into CMake /CLion
include(PVS-Studio.cmake)
pvs_studio_add_target(TARGET analyze
OUTPUT FORMAT errorfile
ANALYZE target LOG target.plog
LICENSE "/path/to/PVS-Studio.lic")
Integration into CMake/QtCreator
include(PVS-Studio.cmake)
pvs_studio_add_target(TARGET analyze
OUTPUT FORMAT errorfile
ANALYZE target LOG target.plog
LICENSE "/path/to/PVS-Studio.lic")
Integration into QMake/QtCreator
pvs_studio.target = pvs
pvs_studio.output = true
pvs_studio.license = /path/to/PVS-Studio.lic
pvs_studio.cfg = /path/to/PVS-Studio.cfg
pvs_studio.cxxflags = -std=c++14
pvs_studio.sources = $${SOURCES}
include(PVS-Studio.pri)
Conclusions made during the
development process
 Installation from a package or a repository
 Getting to know the product using a quick scan
 Integration into a project so that the developer may
have incremental analysis
 Configuring a complete analysis on the build server
 Additional comment - a crazy amount of the Linux projects analyzed, so
that the tool can be considered operational.
Questions?
 Release of PVS-Studio for Linux:
October 25, Tuesday
www.viva64.com
PVS-Studio checks C,C++ and C#

PVS-Studio for Linux (CoreHard presentation)

  • 1.
    What we hadto test and what we learnt during the creation of the Linux version of PVS-Studio Svyatoslav Razmyslov Evgeniy Ryzhkov PVS-Studio www.viva64.com
  • 2.
    Who needs staticcode analysis? • Beginners • «Hindu programmers» • Bad programmers
  • 3.
    MySQL (C++) A lotof similar strings. Everything should be fine. static int rr_cmp(uchar *a, uchar *b) { if (a[0] != b[0]) return (int)a[0] - (int)b[0]; if (a[1] != b[1]) return (int)a[1] - (int)b[1]; if (a[2] != b[2]) return (int)a[2] - (int)b[2]; if (a[3] != b[3]) return (int)a[3] - (int)b[3]; if (a[4] != b[4]) return (int)a[4] - (int)b[4]; if (a[5] != b[5]) return (int)a[1] - (int)b[5]; if (a[6] != b[6]) return (int)a[6] - (int)b[6]; return (int)a[7] - (int)b[7]; }
  • 4.
    CryEngine 3 SDK(C++) inline bool operator != (const SEfResTexture &m) const { if (stricmp(m_Name.c_str(), m_Name.c_str()) != 0 || m_TexFlags != m.m_TexFlags || m_bUTile != m.m_bUTile || ..... m_Sampler != m.m_Sampler) return true; return false; }
  • 5.
    Linux (C) kernel staticint tc_ctl_action(struct sk_buff *skb, struct nlmsghdr *n) { struct net *net = sock_net(skb->sk); struct nlattr *tca[TCA_ACT_MAX + 1]; u32 portid = skb ? NETLINK_CB(skb).portid : 0; .... } The function got an argument: Dereferencing Oops, it should be checked too.
  • 6.
    These bugs haveALWAYS been there. Taken from Cfront compiler, year 1985: Pexpr expr::typ(Ptable tbl) { .... Pclass cl; .... cl = (Pclass) nn->tp; cl->permanent=1; if (cl == 0) error('i',"%k %s'sT missing",CLASS,s); .... }
  • 7.
    Nothing has changedfor the past 30 years. Modern Clang compiler: Instruction *InstCombiner::visitGetElementPtrInst(....) { .... Value *StrippedPtr = PtrOp->stripPointerCasts(); PointerType *StrippedPtrTy = dyn_cast<PointerType>(StrippedPtr->getType()); if (!StrippedPtr) return 0; .... }
  • 8.
    Static analysis methodology Automated code review  Regular checks  The human factor is avoided (it is lowered, to be exact).  Specialized tools. The more the better. But maybe not.
  • 9.
    What did thePVS-Studio users wanted from the Linux version of PVS-Studio?  Command line utility; “We don’t need integration with IDE!”  We don’t need an installer "We will set everything ourselves!»  We don’t need the documentation “We’ll run the program ourselves”
  • 10.
    The first buildand support  The executable file is not a product  Porting the code is only a small part of the work  You cannot make conclusions without full-fledged testing - comparison of testing on Windows and Linux
  • 11.
    Myth of knowingbuild scripts  Not all developers are completely familiar with the build system  People need some way of getting to know the product without integrating and setting up  This method should be quite reliable to leave a good impression from the product
  • 12.
    Support of multipleLinux distributions
  • 13.
    The choice ofthe monitoring technology  (-) Clang scan-build  (+) strace  (+) JSON Compilation Database  (+/-) RD_PRELOAD
  • 14.
  • 15.
    Closed testing ofa Beta version Episode 1  The executable file of the analyzer with the setup script  Online documentation  Several different ways to analyze without the integration
  • 16.
    Closed testing ofa Beta version Episode 2  Support of non-standard compiler extensions  Dealing with false alarms  Creating Deb/Rpm packages  Small tasks concerning the analyzer and the documentation
  • 17.
    Closed testing ofa Beta version Episode 3  We decided not to use the config files for a quick check  Improved work with the log of the strace utilitiy  Work on the DEB/RPM packages  Other tasks concerning the analyzer and the documentation
  • 18.
    Closed testing ofa Beta version Episode 4 (Release Candidate)  Heading towards the integration into large projects  Implementation of various user requests  Our own repositories for DEB/RPM packages*
  • 19.
    Integration into Makefile/Makefile.am .cpp.o: $(CXX)$(CFLAGS) $(DFLAGS) $(INCLUDES) $< -o $@ pvs-studio --cfg $(CFG_PATH) --source-file $< --language C++ --cl-params $(CFLAGS) $(DFLAGS) $(INCLUDES) $<  Details in the analyzer setup  Incremental analysis  Parallelization of the analysis on the build system level  Other pluses of the build system
  • 20.
    Integration into CMake/CLion include(PVS-Studio.cmake) pvs_studio_add_target(TARGET analyze OUTPUT FORMAT errorfile ANALYZE target LOG target.plog LICENSE "/path/to/PVS-Studio.lic")
  • 21.
    Integration into CMake/QtCreator include(PVS-Studio.cmake) pvs_studio_add_target(TARGETanalyze OUTPUT FORMAT errorfile ANALYZE target LOG target.plog LICENSE "/path/to/PVS-Studio.lic")
  • 22.
    Integration into QMake/QtCreator pvs_studio.target= pvs pvs_studio.output = true pvs_studio.license = /path/to/PVS-Studio.lic pvs_studio.cfg = /path/to/PVS-Studio.cfg pvs_studio.cxxflags = -std=c++14 pvs_studio.sources = $${SOURCES} include(PVS-Studio.pri)
  • 23.
    Conclusions made duringthe development process  Installation from a package or a repository  Getting to know the product using a quick scan  Integration into a project so that the developer may have incremental analysis  Configuring a complete analysis on the build server  Additional comment - a crazy amount of the Linux projects analyzed, so that the tool can be considered operational.
  • 24.
    Questions?  Release ofPVS-Studio for Linux: October 25, Tuesday www.viva64.com PVS-Studio checks C,C++ and C#