From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2804 invoked by alias); 14 Dec 2013 00:38:54 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 2794 invoked by uid 89); 14 Dec 2013 00:38:53 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-we0-f171.google.com Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com) (74.125.82.171) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Sat, 14 Dec 2013 00:38:52 +0000 Received: by mail-we0-f171.google.com with SMTP id q58so2596783wes.16 for ; Fri, 13 Dec 2013 16:38:48 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.180.198.115 with SMTP id jb19mr4982737wic.28.1386981528872; Fri, 13 Dec 2013 16:38:48 -0800 (PST) Received: by 10.216.236.71 with HTTP; Fri, 13 Dec 2013 16:38:48 -0800 (PST) Date: Sat, 14 Dec 2013 00:38:00 -0000 Message-ID: Subject: [C++] Warning Header Proposal From: Ben Longbons To: gdb@sourceware.org Content-Type: text/plain; charset=UTF-8 X-SW-Source: 2013-12/txt/msg00021.txt.bz2 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)