Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Pedro Alves <palves@redhat.com>
To: Ben Longbons <brlongbons@gmail.com>
Cc: gdb@sourceware.org
Subject: Re: [C++] Warning Header Proposal
Date: Mon, 16 Dec 2013 15:17:00 -0000	[thread overview]
Message-ID: <52AF195B.8090803@redhat.com> (raw)
In-Reply-To: <CA+XNFZNU8CQYnGoM-FvD9ya9rfoAUw7Mzr=eaUGU7uvWryOaNQ@mail.gmail.com>

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


  reply	other threads:[~2013-12-16 15:17 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-14  0:38 Ben Longbons
2013-12-16 15:17 ` Pedro Alves [this message]
2013-12-16 19:27   ` Ben Longbons

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=52AF195B.8090803@redhat.com \
    --to=palves@redhat.com \
    --cc=brlongbons@gmail.com \
    --cc=gdb@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox