[C++] Warning Header Proposal

Ben Longbons <[email protected]>
Newsgroups gmane.comp.gdb.devel
Message-ID <CA+XNFZNU8CQYnGoM-FvD9ya9rfoAUw7Mzr=eaUGU7uvWryOaNQ@mail.gmail.com>
Under the assumption that most active gdb maintainers intend that
future gdb releases be written in C++, I am presenting a possible plan
for the conversion, based on my experience with a conversion about
1/5th the size of gdb.

I have found 3.5 areas of discussion, 2.5 of which I have actually written.
- System Requirements
- Attack Plan
-- Warning Header Proposal
- Style Guide (to be written, probably not by me)

A shared editing pad is available at http://piratepad.net/gdb-cxx, it
will contain links to the archived mails so don't be concerned about
editing what I wrote there.

This thread will discuss my proposal to make warning management easier
by using a header file.

This is a somewhat controversial proposal, so I split it from the Attack Plan.

The second step that I propose is to introduce a new mechanism for
managing warnings. This would apply only in development mode, because
for full effectiveness, it requires #pragma GCC diagnostic to apply
inside functions. This requires editing the autoconf file to add to
CPPFLAGS only under gdb/

The specific change I propose is, insteading of adding warnings by an
autoconf test, hard-code them according to compiler version. Despite
sounding like a step backward, this is actually a step forward,
because:
- I have a list of every single warning supported by gcc 4.6, 4.7, and
4.8 in C++ mode (the initial version of the file in C mode will be
limited unless someone wants to fill it, but I don't see the point.
Note that gcc documentation is not always accurate about which
warnings are applicable in which modes).
- Given the warning header, it very easy to flip one between "don't
care", "ignore", "force to warning even with --enable-werror",
"warning or error depending on --enable-werror", and "force error
always"
- Compared to a @file, there may be comments in a header.
- Compared to adding every single warning to the command line, this
keeps the length of the compiler line readable. Currently, gdb enables
very few compiler warnings. Hm, since the autoconf-added ones will be
in the header anyway, is there a way to tell autoconf to *not* add
-Wfoo to CPPFLAGS in gdb/ ? Well, I guess we could just never add them
and pass something like: -DGDB_STRICT_WARNINGS while in gdb/ ... or
just wait for the c++ conversion and check __cplusplus.
- Compared to using autoconf, the header is much more accessible by
ordinary developers. It might not appear so to those of you who are
familiar with it, but autoconf is *insane*. I gave it a sincere
effort, but eventually I just gave up and wrote my own ./configure
script and toolset.
- Compared to autoconf, we can rely on warnings actually *working*
instead of just assuming that the option works just because the
compiler recognizes it. A particularly notorious example is -Wshadow,
which is only useful since gcc 4.8 but has been recognized since
(insert ridiculously ancient event here). Admittedly, it's *possible*
to write a test for exactly the positive and negative cases, but are
you really going to do that?

I intend to do some things differently for gdb, but for reference, the
warning file I currently use is
https://github.com/themanaworld/tmwa/blob/test/src/warnings.hpp
Particularly, I do not think it is worth trying to get meaningful
warnings out of clang.


Thanks for your time,
Ben Longbons (o11c on IRC)
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.