Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Daniel Jacobowitz <drow@false.org>
To: Eli Zaretskii <eliz@gnu.org>
Cc: gdb-patches@sourceware.org
Subject: Re: RFC: Use -Wall -Wextra
Date: Fri, 29 Dec 2006 21:02:00 -0000	[thread overview]
Message-ID: <20061229210206.GA23681@nevyn.them.org> (raw)
In-Reply-To: <usley300m.fsf@gnu.org>

On Fri, Dec 29, 2006 at 10:44:25PM +0200, Eli Zaretskii wrote:
> > I definitely don't want to back away from -Werror: I think it's done
> > us a lot of good.
> 
> I'm not against -Werror, I just don't trust GCC to not flag some
> innocent code as questionable under -Wall -Wextra.  These flags are
> for those who intentionally want a noisy compiler; adding -Werror to
> them is asking for too much trouble.

How about -Wall without -Wextra then?  This is the compromise adopted
by binutils and GCC.

> > I enabled -Wextra mostly because I wanted -Walways-true
> 
> IMO -Walways-true is one of the greatest nuisances with the latest GCC
> versions.  Some code, especially sophisticated macros that need to
> work portably with different data sizes, simply cannot be made to work
> around this warning, especially if you want to handle 32-bit and
> 64-bit machines.  There already are such problems in GNU Make and in
> Emacs, and developers are unwilling to fix them because it's too much
> trouble, if at all possible.

I think neither of us is actually talking about -Walways-true.  It
doesn't seem to control what I thought it did.  Anyway, I was looking
for the "comparison of unsigned >= 0 is always true" warning
specifically.  The only thing controlling that is -Wextra.  I suspect
that's the one you are concerned about, too.

I'd like to enable that warning but I won't cry if we agree not to. It
did find one bug in GDB already, and would have found another if it had
been enabled (the ia64-tdep bug I fixed yesterday).  But I can build
with it locally on systems where I know it isn't a big problem.

> Those issued by -Walways-true and the ones that wine about mismatch
> between pointers to signed and unsigned char are the two that come to
> mind.

I actually think the latter is useful, but not useful enough to
continue fixing up GDB for it - my patch left that one disabled,
deliberately.  Let's not go back there again, it was a real nuisance.

> > > I'd advise against -Wunused: the problems it finds are harmless,
> > > whereas fixing them is not trivial at all, and quite ugly in some
> > > cases.
> > 
> > I'm afraid I don't understand this either.  The problems -Wunused finds
> > are usually very easy to fix.
> 
> You mean with "i = i;"?

No, either by deleting the unused local variable if it's truly unused,
or by adding ATTRIBUTE_UNUSED if it is conditionally unused (or
avoiding conditional compilation).

>     gcc -c -g -O2    -I. -I. -I./config -DLOCALEDIR="\"/usr/local/share/locale\"" -DHAVE_CONFIG_H -I./../include/opcode -I./../readline/.. -I../bfd -I./../bfd -I./../include   -DMI_OUT=1 -DTUI=1  -Wall -Wextra -Wpointer-arith -Wformat-nonliteral -Wno-pointer-sign -Wno-unused-parameter -Wno-unused -Wno-sign-compare -Wno-switch -Wno-missing-field-initializers -Werror infrun.c
>     cc1: warnings being treated as errors
>     infrun.c: In function 'handle_inferior_event':
>     infrun.c:1458: warning: statement with no effect
>     make[2]: *** [infrun.o] Error 1

Thanks.  That comes from the default definition of a macro which no
longer has any non-default definitions; we may as well garbage collect
it.  I don't know why I didn't get the warning; I can provoke it for
a small testcase.

I'll remove the macro, since that's an unrelated cleanup.

-- 
Daniel Jacobowitz
CodeSourcery


  reply	other threads:[~2006-12-29 21:02 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-12-28 19:55 Daniel Jacobowitz
2006-12-29 12:13 ` Eli Zaretskii
2006-12-29 13:58   ` Daniel Jacobowitz
2006-12-29 20:44     ` Eli Zaretskii
2006-12-29 21:02       ` Daniel Jacobowitz [this message]
2006-12-30 15:32         ` Eli Zaretskii
2006-12-30 16:00           ` Daniel Jacobowitz
2006-12-30 16:55             ` Eli Zaretskii
2007-01-03 19:12             ` Daniel Jacobowitz
2007-01-03 20:38               ` Mark Kettenis
2007-01-04  4:09               ` Eli Zaretskii
2007-01-04 19:42               ` Daniel Jacobowitz

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=20061229210206.GA23681@nevyn.them.org \
    --to=drow@false.org \
    --cc=eliz@gnu.org \
    --cc=gdb-patches@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