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
next prev 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: linkBe 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).