This lab will give you the opportunity to explore some of the kinds of problems that static analysis tools can help you with. This will be a fairly basic exercise. We won’t be installing any new tools for this lab – just making some better use of an already familiar tool, the g++
compiler.
We will look at some more advanced tools later in the sememster.
Set up a C++ project to use in this lab. You can use any IDE, though if you have been working through the earlier assignment on Eclipse, it would probably make the most sense to use that. But you can use Code::Blocks or even emacs. You are going to be doing a lot of stepping though error messages and examining the associated code, so pick somethings that does that job well.
Your C++ code for this project should be reasonably complicated. It should involve multiple .cpp files and some use of classes. It might even be something that you never got working correctly, though it should compile.
Build (compile) your project in the normal fashion. Most IDEs will display somewhere the compilation commands that they are running on your behalf. Take note of these. (In Eclipse, you can find these in the Console
tab of the bottom central window.)
Also take note of any compiler warnings that were issued. (Presumably you did not get actual errors that owuld have prevented compilation.) Step through these warnings and take note of the kind of things the compiler is brining to your attention.
The -Wall
flag, added to a g++
compilation, causes the compiler to emit warnings for a number of practices that, in the opinion of the g++
designers, are both questionable and easily avoided.
Some of the things checked by -Wall
include
-O2
char
in array subscriptsprintf
…
You can find the full list here, which is best read with a separate browser window open to this index.
If your project build does not already include -Wall
, add it to the compiler options. (See Changing Compiler Options below.)
Rebuild your project. (You may need to clean/clear the project first to force a full rebuild, because you have not actually touched any of the source code.)
If your project build already included -Wall
, try removing it and rebuilding. Any changes?
Walk through the messages now. Do you see any changes? If not, try adding one of the problems described earlier as being under the purview of -Wall
and rebuild again.
Take particular note of any messages that indicate a true potential problem with your code. Take note also of nay false alarms, things that you know are OK even though they were flagged. (Keep your mind open, at least, to the possibility that there may be potential problems that you aren’t aware of.)
Any surprises? Discover any hidden problems? Or, maybe, just find some of the warnings you got to be inexplicable? Post about your experiences in the Hallway Forum.
-Wextra
adds still more checks, including warning for empty loop and if
bodies, comparisons between signed and unsigned integers, and parameters to functions that are never used in the function body.
-Wextra
in addition to -Wall
.Weffc++
adds warnigns for a number of issues from Scott Meyers’ Effective C++ and More Effective C++.
These include warnings if you fail to implement your own version of the copy constructor and assignment operator for classes that have dynamic allocation. (You should recall discussions of the C++ Rule of the Big 3 from your earlier courses.) Also flagged are operator=
implementations that fail to return *this
, and the use of assignment rather than initialization within constructors.
-Weffc++
in addition to -Wall
.These options can give you early warning of potential problems, but only if you actually read and consider the warning messages. The struggle with most static analysis regimens is to balance the value of the legitimate warnings against the annoyance of wading through many false alarms.
Read on if you are not familiar with the process of changing the options used to compile C++ code in your favorite IDE.
If you are using emacs as your IDE, you are probably using a make file to control your build.
Look in the make file for the actual g++
commands and add the desired option there.
It’s a common style among writers of make files to invoke the compiler via a variable name, usually “CXX”, e.g.,
CXX=g++
⋮
$(CXX) -o $@ -c $*.cpp
The reason is that this make file can then easily be modified to use a different compiler by changing that variable. In fact, it can be changed directly from the command line. For example, if I wanted to generate a Windows executable when running the compiler on a Linux box, I say
make -DCXX=CXX=x86_64-w64-mingw32-g++
to use a Windows cross-compiler instead of the normal g++
.
It’s also common to package the compilation options in a variable. For example, I often use CPPFLAGS
, in conjunction with a rule like:
CXX=g++
CPPFLAGS=-g -std=c++11
%.o: %.cpp
$(CXX) $(CPPFLAGS) -MMD -o $@ -c $*.cpp
So any change to the CPPFLAGS
variable would update all compilations generated by this make file.
To change C++ compilation options in Eclipse, much depends on whether you are using the Eclipse build-in project manager or a separate make file to control the build. If you are using a make file, then follow the instructions given above.
If you are working with the built-in manager, go to the Project menu and select Properties
, `C/C++ Build“, ”Settings“, then the ”Tool Settings“ tab. You can then select the option flags you want directly in the ”GCC C++ Compiler“ ”Warnings“ or ”Miscellaneous“ area. Note that when you select an option in one of these areas, then it gets added to the summary ”All options“ at the ”GCC C++ Compiler" area.
From the Project
menu, select Build Options
, then Compiler
Settings
. You can then try to select your desired option form the description in Compiler Flags
or type it in directly under Other
options
.