GCC Warning Messages
Recently (in the 15 series) we turned on the -Wall option for
compiling code on Linux (we disable a couple of specific warnings as
we don't believe those are useful). We believe that it is valuable to
look at the code the compiler points out as having a potential
problem. However, clearly code should not be obfuscated or potential
bugs introduced with the aim of making the compiler quiet. There could
be good reasons to have coded something a particular way that the
compiler doesn't like.
This page will document typical warnings that will be seen, why
they are warnings and how they should be dealt with. If you see
warning that isn't described here please post it to Programming
Questions HN. Also, if you are unsure of how to fix something,
please post there too.
implicit typename is deprecated
If you see an error of the form;
Compiling RgtAddressLineScan.cc [libRegrTest.a] [cc-1]
/u1/drjohn/bfdist/packages/RegrTest/V00-03-01/RgtAddressLineScan.cc: In
function `int <unnamed>::index(std::vector<Type, std::allocator<_CharT> >&,
const Type&)':
/u1/drjohn/bfdist/packages/RegrTest/V00-03-01/RgtAddressLineScan.cc:73: warning: `
typename std::vector<Type, std::allocator<_CharT> >::const_iterator' is
implicitly a typename
/u1/drjohn/bfdist/packages/RegrTest/V00-03-01/RgtAddressLineScan.cc:73: warning: implicit
typename is deprecated, please see the documentation for details
this is because the C++ standard rule is that every identifier that
involves a template is interpreted as a value unless it is explicitly
qualified as a typename.
Thus, when you write;
vector<T>::const_iterator i;
const_iterator may be interpreted as a static member of the class
vector<T>. To make it clear that it is the type that declares
the value i, one needs to write;
typename vector<T>::const_iterator i;
`XXX' defined but not used
If you see a warning like;
Compiling testhist_l.cc [libRegrTest.a] [cc-1]
testhist.l:451: warning: `void yyunput(int, char*)' defined but not used
this means there is a function implemented but not actually
used.
It should be safe to remove this function and reduce the overall
size of BaBar code. (In this particular case this code is
auto-generated so it isn't possible to fix this warning).
declaration of `XXX' with no type
If you see a warning like;
Compiling addressTest.cc [addressTest.o] [cc-3]
/u1/drjohn/bfdist/packages/RegrTest/V00-03-01/addressTest.cc:43: warning: ISO
C++ forbids declaration of `main' with no type
/u1/drjohn/bfdist/packages/RegrTest/V00-03-01/addressTest.cc: In function `int
main()':
this means that a function has been declared without a return
type. This is not legal.
You should declare a return type. If there is no value returned the
type would be void . Make sure each return statement from
the function does actually return the correct type (including none, if
void
unused variable `XXX'
If you see a warning like this;
Compiling addressTest.cc [addressTest.o] [cc-3]
/u1/drjohn/bfdist/packages/RegrTest/V00-03-01/addressTest.cc:45: warning: unused
variable `ThisClass*c'
It means a variable has been declared but is not used. This will
use up memory for no good reason.
You can remove the declaration of this variable. However, make sure
you only remove the declaration and not any actual code. For example
there may be code like;
bool result = doSomething();
where removing the whole like would introduce a bug. You could
remove only the bool result = part of the like to avoid
introducing the bug, although you may ask yourself if you should
really be checking result instead of removing it.
`XXX' might be used uninitialized
If you see a warning like;
Compiling begback.F [libbeget.a] [F-1]
begback.F: In subroutine `begback':
begback.F:46: warning: `nxing' might be used uninitialized in this function
you should convince yourself that the variable is actually
initialised prior to being used.
`ffkey' is one type
If you see a warning of the type;
Compiling begbhwideff.F [libbeget.a] [F-1]
begbhwideff.F: In subroutine `begbhwideff':
begbhwideff.F:51: warning:
CALL FFKEY('BHNP',BHNPAR, 5, 'INTEGER')
1
begbhwideff.F:75: (continued):
CALL FFKEY('BHSC', BHSCATT, 4, 'REAL')
2
Argument #2 of `ffkey' is one type at (2) but is some other type at (1) [info -f g77 M GLOBALS]
this is due to the way this function is implemented and cannot be
fixed.
This file includes at least one deprecated
If you see a warning like;
Compiling AbsParmIfdStrKey.cc [libAbsParm.a] [cc-1]
In file included from /usr/include/c++/3.2.3/backward/strstream:51,
from /u1/drjohn/bfdist/packages/AbsParm/V00-08-01/AbsParmIfdStrKey.cc:31:
/usr/include/c++/3.2.3/backward/backward_warning.h:32:2: warning: #warning This
file includes at least one deprecated or antiquated header. Please consider using one of the 32 headers found in section 17.4.1.2 of the C++ standard. Examples
include substituting the <X> header for the <X.h> header for C++ includes, or <sstream> instead of the deprecated header <strstream.h>. To disable this warning
use -Wno-deprecated.
this means you are using a classic IOStreams header file. Currently
the main reason for this is use of <strstream>. This should be
replaced with using <sstream> some notes are available on making this
change.
If you see this for other reasons please report it to Programming
Questions HN.
will be re-ordered to match declaration order
If you see a warning of the type;
Compiling BFieldIntegrator.cc [libBField.a] [cc-1]
/u1/drjohn/bfdist/releases/nightly-20040907/BField/BFieldIntegrator.hh: In
constructor `BFieldIntegrator::BFieldIntegrator(const BField&)':
/u1/drjohn/bfdist/releases/nightly-20040907/BField/BFieldIntegrator.hh:90: warning: member
initializers for `double BFieldIntegrator::_stepCeiling'
/u1/drjohn/bfdist/releases/nightly-20040907/BField/BFieldIntegrator.hh:88: warning:
and `double BFieldIntegrator::_pathMin'
/u1/drjohn/bfdist/packages/BField/V00-05-00/BFieldIntegrator.cc:25: warning:
will be re-ordered to match declaration order
/u1/drjohn/bfdist/releases/nightly-20040907/BField/BFieldIntegrator.hh:94: warning: member
initializers for `double BFieldIntegrator::_divStepCeiling'
/u1/drjohn/bfdist/releases/nightly-20040907/BField/BFieldIntegrator.hh:92: warning:
and `double BFieldIntegrator::_divPathMin'
/u1/drjohn/bfdist/packages/BField/V00-05-00/BFieldIntegrator.cc:25: warning:
will be re-ordered to match declaration order
this means the order of the member variables in the header file do
not agree with the order they are written in the constructor. The
compiler is telling you that the actual initialisation order is that
which is defined in the header file (which is part of the C++
Standard). Potentially you could have been mistaken about the order so
it is a good idea to reorder the constructor to agree with the header
file.
Page author(s):
Stephen J. Gowdy,
Rainer Bartoldus
| Last significant update: 11-Oct-2004 |
Expiry date: 8-Sep-2005 |
|
