From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19654 invoked by alias); 16 Dec 2013 15:17:01 -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 19645 invoked by uid 89); 16 Dec 2013 15:17:00 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 16 Dec 2013 15:16:59 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id rBGFGu7Y002403 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 16 Dec 2013 10:16:56 -0500 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id rBGFGsAG021843; Mon, 16 Dec 2013 10:16:55 -0500 Message-ID: <52AF195B.8090803@redhat.com> Date: Mon, 16 Dec 2013 15:17:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: Ben Longbons CC: gdb@sourceware.org Subject: Re: [C++] Warning Header Proposal References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2013-12/txt/msg00032.txt.bz2 Hi Ben, On 12/14/2013 12:38 AM, Ben Longbons wrote: > This is a somewhat controversial proposal, so I split it from the Attack Plan. Yes, this looks quite orthogonal to C++ to me. > 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 read the whole email, but I fear it still sounds a step backwards to me. > - 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. gnulib/manywarnings.m4 also has something like that, and that's sure to be used by other GNU programs. If we were to change, I'd rather see gnulib's warnings modules grow smart enough for our use (if necessary) and switch to that. > - 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" "warning header" vs "warnings in command line" is orthogonal to "decide which warnings to use based on version checks vs "decide which warnings to use depending on autoconf tests". The latter can just as well create a warning header. > 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/ ? No sure what you mean. There's -Wno-foo. > - Compared to autoconf, we can rely on warnings actually *working* > instead of just assuming that the option works just because the > compiler recognizes it. Sorry, that doesn't follow. We absolutely can test that the warning actually works with autoconf. And that's something you can't do with version checks. That's the sort of thing autoconf is exactly meant for. The fact that we don't do it in this particular case doesn't mean it can't be done. > 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? Why not? -- Pedro Alves