Hi all,
Here at Sun Hamburg, we are eager to get OOo's C/C++ code base warning
free. We plan to do this massive (in number of files affected) change
for post--OOo-2.0. Since doing these changes needs close collaboration
(think of headers from one module that only cause warnings once they are
used in another module, for example), we initially plan to do this with
a Hamburg-only group of engineers, working together on (a single
physical copy of) CWS warnings01. If the work becomes too boring for
us, we may start to ask for help from the community... ;)
This mail contains three sections. In the first section, I repeat the
publicly relevant parts of the Hamburg-internal kick-off meeting
minutes, written by Malte Timmermann, which put this effort into
perspective and give some further details.
In the second section, I explain what I have done so far to get CWS
warnings01 going, so that the other (Hamburg-internal) engineers can
start to do their part of the work.
In the third section, I give a quick overview of where we need input
from the community.
1 KICK-OFF MEETING MINUTES
Reasons for this effort
Warning free code is a basic precondition for robust industrial quality
code. This as well is current scientific knowledge as the result of the
personal experience of Hamburg-internal engineers, as well as the
opinion of some OpenOffice.org developers like e.g. Ken Foskey.
The main argument against it seems to be, that many warnings are no real
bugs, the code "works" well, and so there would be no time to fix them.
Some reasons, why we think it necessary to write warning free code
nevertheless:
1. Most warnings are a hint, that either part of the code is not
completely "thought to the end" or something in the depending code has
changed or they show inconsistencies. While such occurrences are not
always bugs themselves, they show potential problems, that well may
occur after the next code change.
2. Warnings are an important source of information. If the mass of
warnings is not fixed, the really important ones can not be found in the
crowd.
3. A huge number of warnings is an indicator for not robust enough code.
4. We found, that the warnings of gcc give the most positive sensible
and the least false positive results. Therefore we choose that as the
warning set to orientate for.
5. The daily practice of many software engineers shows that it is quite
manageable to write warning free code. Like any habit, after getting
used to it, it does not cost any significant additional time in daily work.
Current Status and Planing of CWS warnings01
In the first round, we will fix all GCC warnings on Linux, after that
the remaining warnings on Windows and Solaris.
The initial goal was to use the default warning set, but the team
decided that they want to start with “wall=true” and see if they can
avoid all warnings on that level. If so, wall=tr will become the default
later.
It can happen that a module compiles fine without warnings, but delivers
some header files which lead to warnings in other modules. To avoid
this, we should test all delivered header files. This could be done with
the old “testhxx”.
If someone think it's reasonable to suppress a warning, this must be
discussed with the team members. It should also be discussed in public,
using the mailing list [EMAIL PROTECTED] Please start the subject with
“compiler warnings:”.
In external projects we only want to fix the header files. In case we
want warnings to become errors later, to keep the code warning free (not
decided yet), we must find a solution for this modules.
We discussed that all modules should be build with exception handling
turned on, because this avoids a lot of warnings in some modules.
The team members should also have a look at the 64-bit CWS (ooo64bit02)
to see what data sizes they already changed.
When typecasting string length, please use XubStrLen instead of USHORT
(old tools String), so it's easier to find them in case we change the
old String to 32bit some time. This might also be a good idea for some
other sizes, e.g. from tools/svtools containers.
2 FIRST WORK ON LOW-LEVEL MODULES
I started builds for all Hamburg-relevant platforms (unxlngi6,
unxlngi6.pro, unxsoli4.pro, unxsols4, unxsols4.pro, wnmtsci10,
wntmsci10.pro). On unxlngi6.pro (the platform we want to focus on
first), I now reached a point where others can probably pick up and
start work on their part of the module tree. I did the following
changes until now:
- To improve consistency, and to ease further modifications, handling of
C/C++ compiler warning switches in solenv has been changed as follows:
- CFLAGSDFLTWARN has been replaced by two new variables CFLAGSWARNCC
(C compiler) and CFLAGSWARNCXX (C++ compiler); if on some platform
CFLAGSWARNCXX is not set, CFLAGSWARNCC is used instead;
- CFLAGSWALL has been replaced by two new variables CFLAGSWALLCC (C
compiler) and CFLAGSWALLCXX (C++ compiler); if on some platform
CFLAGSWALLCXX is not set, CFLAGSWALLCC is used instead;
- CFLAGSWARNCC/CXX and CFLAGSWALLCC/CXX are no longer added to
CFLAGSAPPEND (so that they appear at the end of the compiler command
line), but rather to CFLAGSCC/CXX (which means that they appear at an
arbitrary place within the compiler command line); to make this work, on
all platforms, all warning-related compiler switches that had previously
been added to some other CFLAGS... variable have been moved to
CFLAGSWARNCC/CXX and/or CFLAGSWALLCC/CXX.
- Added build switch werror=1 that turns on new COMPILER_WARN_ERRORS,
which in turn adds new CFLAGSWERRCC/CFLAGSWERRCXX to CFLAGSCC/CXX
(unless EXTERNAL_WARNINGS_NOT_ERRORS is set, see below); if on some
platform CFLAGSWERRCXX is not set, CFLAGSWERRCXX is used instead.
- Added EXTERNAL_WARNINGS_NOT_ERRORS that can be specified in
makefile.mk of external code ("EXTERNAL_WARNINGS_NOT_ERRORS=TRUE") to
suppress COMPILER_WARN_ERRORS (see above).
- Changed STLport so that no warnings at all are generated from its
headers. On unxsoli4 and unxsols4 this has the drawback that the
warnings inllargeuse ("function is too large and will not be expanded
inline") and notemsource ("Could not find source for function") are
globally disabled in each compilation unit (regardless of whether or not
it includes an STLport header), because those warnings seem to only be
generated at the end of a compilation unit. On wntmsci10 this has the
drawback that whenever an STLport header is included in a compilation
unit, the warnings 4514 ("unreferenced inline function has been
removed") and 4710 ("function not inlined") are globally disabled in
that compilation unit from that point on, because those warnings seem to
only be generated at the end of a compilation unit.
- Added SAL_INT_CAST (for C) and std::static_int_cast and
std::reinterpret_int_cast (for C++) to sal/types.h and brought in
sal_IntPtr and sal_uIntPtr to sal/types.h from CWS ooo64bit02. See the
documentation in sal/types.h for when this new functionality should be used.
- Open issues:
- soltools/HIDCompiler/makefile.mk: unused functions/labels in
flex-generated code.
- idlc/source/makefile.mk: comparisons between signed and unsigned
integer expressions in bison-generated code, and unused function in
flex-generated code. (The current work-around for this affects other
source files in the same directory, too!)
- I placed a little script testhxx.unxlngi6 into the root directory of
CWS warnings01 (thus only visible Hamburg-internally right now). It can
be used on unxlngi6 and unxlngi6.pro to check whether a delivered header
(passed as argument to the script) passes through the C++ compiler
flawlessly in wall=1 werror=1 mode. Similar scripts for other platforms
will follow (and we should think of a better place to store them). The
script uses the environment variables SOLARINC, JDKINCS, UPD, PROSWITCH,
and WORK_STAMP from the build environment; since SOLARINC includes "."
(the current working directory), you should not execute testhxx.unxlngi6
from within a directory that includes any header files.
3 WE NEED YOU!
Here at Hamburg, we will only concentrate on those platforms we build
ourselves. Also, due to the fact that our build environment is slightly
different from a typical OOo build environment, we may miss some points
that will only be noticed by the community. So, we depend on your input
for code specific to platforms other than Linux x86, Solaris Intel,
Solaris SPARC, and Windows, and for issues that are hidden by our
Hamburg build environment. However, as I already wrote above, to keep
work on this CWS smooth, please be patient with us and wait until we
have reached a state where we can incorporate that input.
Of course, if you have any concerns, ideas, whatever right now---give
feedback right now.
-Stephan
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
