public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Paul Schlie <schlie@comcast.net>
To: Alan Modra <amodra@bigpond.net.au>
Cc: Ben Elliston <bje@au1.ibm.com>, <binutils@sources.redhat.com>,
	Nick Clifton <nickc@redhat.com>
Subject: Re: Add -Werror to build_warnings
Date: Fri, 18 Feb 2005 15:58:00 -0000	[thread overview]
Message-ID: <BE3ADA6B.9213%schlie@comcast.net> (raw)

> From: Alan Modra <amodra@bigpond.net.au>
>> - and/or recommend that GCC-4.0 eliminate that frivolous warning by default.
> I'm not going to do any such thing.  I rather like the fact that gcc-4.0
> has more warnings, despite it causing some work to make our code warning
> free.  Case in point: Better analysis of uninitialized variables found
> two places in binutils where we really could use an uninitialized
> variable in corner cases.  It also warned about 4 or 5 other places that
> were not real problems.  That's a very good ratio.  I'll take 100 false
> positives if a compiler finds me one real error..

- Fully understand your position in general, however honestly question the
  utility of the specific warning: of a comparison between two pointers to
  otherwise equivalent rank data types which only in sign-ness; as it's not
  clear that such a comparison could ever lead to unintended consequences,
  as even arguably evidenced by the apparent intent to disable it, rather
  than be alerted of such comparisons by default (presumably as it's not
  perceived as likely helpful)?  However would very much appreciate an
  example to the contrary, as I'm obviously confused by it's purpose, as
  the sign-ness of a data type seems irrelevant when attempting to compare
  the addresses two otherwise compatible data types?

  (but not a big deal, as the warning may easily be disabled as desired)


             reply	other threads:[~2005-02-18  4:34 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-02-18 15:58 Paul Schlie [this message]
2005-02-18 16:05 ` Zack Weinberg
2005-02-18 16:08   ` Paul Schlie
2005-02-18 16:23 ` Alan Modra
  -- strict thread matches above, loose matches on Subject: below --
2005-02-18  6:33 Paul Schlie
2005-02-18 14:34 ` Alan Modra
2005-02-16  5:01 Ben Elliston
2005-02-16  6:30 ` Alan Modra
2005-02-16  7:27   ` Ben Elliston
2005-02-16 13:01     ` Nick Clifton
2005-02-18  2:56   ` Alan Modra

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=BE3ADA6B.9213%schlie@comcast.net \
    --to=schlie@comcast.net \
    --cc=amodra@bigpond.net.au \
    --cc=binutils@sources.redhat.com \
    --cc=bje@au1.ibm.com \
    --cc=nickc@redhat.com \
    /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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).