------- 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
