[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)