public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "veksler at il dot ibm dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/21951] [gcc-4.0 regression, rejects-valid] std::vector.reserve() unusable with -Werror -Wall -O -fno-exceptions
Date: Tue, 07 Jun 2005 19:46:00 -0000	[thread overview]
Message-ID: <20050607194642.29638.qmail@sourceware.org> (raw)
In-Reply-To: <20050607175818.21951.dank@kegel.com>


------- Additional Comments From veksler at il dot ibm dot com  2005-06-07 19:46 -------
(In reply to comment #3)
>  Paolo I copied the quote fully when I really should not have.  RTH did not
know we could not fix the 
> if(0) part in libstdc++ at the time he wrote that comment, if you read the
next comment in that bug I 
> explain why it cannot be fixed in libstdc++ (comment #3 in PR 19699):
> (In reply to comment #2)
> > You may retartget this pr to fixing the silliness in libstdc++, if you want.
> Actually it is only silliness as try/catch is changed to be "if (true)"/"if
(false)" if we don't have exceptions.  
> There is nothing can be done to the libstdc++ headers to fix this.

I disagree. libstdc++ can do exactly what everybody else does in such cases:
 add a dummy (unreachable) "return __result" at the end, after both try
 and catch blocks.

This will be a hack, no doubt, a pragmatic one. I don't think that emitting
false positive diagnostic that the user does not control is a good thing.
I have been working in a verification (research) department for 10 years,
and I can assure you that false positives, which can't be turned off, 
are worse than no diagnostic at all. Such diagnostics *will* turn
customers/users away from your tool, or at best "just" ignore diagnostics.

I have used a (bought) tool that gave a false positive every 500 lines of
code. For 500 KLOC it would give 1K false positive. Now, try to find out a
single true bug out of the noise of 1000 false positives. I can tell you that
the tool was dropped very fast.

We write tools used for verification and testing. Our customers are more likely
to be willing to live with uncovered events, than to get false positives. Think
of millions of tests/events that cause even 0.1% of false positive. These may
overshadow hundreds of real bugs.

Same with gcc, if something as central as vector.reserve() give false positive
diagnostics then the sheer volume of warnings will render either the warning
or reserve() unusable.

I suggest to reopen PR19699 against libstdc++ (or maybe open a new one)

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21951


  parent reply	other threads:[~2005-06-07 19:46 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-06-07 17:58 [Bug c++/21951] New: " dank at kegel dot com
2005-06-07 18:00 ` [Bug c++/21951] " pinskia at gcc dot gnu dot org
2005-06-07 18:12 ` pcarlini at suse dot de
2005-06-07 18:17 ` pinskia at gcc dot gnu dot org
2005-06-07 19:46 ` veksler at il dot ibm dot com [this message]
2005-06-07 23:28 ` [Bug libstdc++/21951] " bangerth at dealii dot org
2005-06-08 13:20 ` [Bug libstdc++/21951] [4.0 only] " pinskia at gcc dot gnu dot org
2005-06-08 13:57 ` dank at kegel dot com
2005-06-08 14:11 ` veksler at il dot ibm dot com
2005-06-08 14:43 ` veksler at il dot ibm dot com
2005-06-08 19:16 ` bkoz at gcc dot gnu dot org
2005-06-11 11:25 ` dank at kegel dot com
2005-06-11 19:29 ` dank at kegel dot com
2005-06-12 15:02 ` pinskia at gcc dot gnu dot org
2005-07-01 19:10 ` geoffk at gcc dot gnu dot org
2005-07-01 19:42 ` dank at kegel dot com
2005-07-16 21:12 ` pinskia at gcc dot gnu dot org

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=20050607194642.29638.qmail@sourceware.org \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).