Re: Recent warning regression in libstdc++-v3/libsupc++

[Mark Mitchell <mark at codesourcery dot com>]

Paolo Carlini wrote:

> Now, however, I'm not sure to understand which kind of way forward
> you can see... Should the warning machinery be smart enough to not
> warn at all in this case? Or? Sorry, probably it's just my ignorance
> about those issues at the interface between core and library, I would
> really appreciate a bit of additional guidance.

Sorry, I may have answered some other question than the one I should 
have. :-)

I don't think this is easy.  This is a function in the library, but one 
the compiler needs to know about.  So, should the compiler warn if the 
declaration doesn't match its expectations?  I think the answer is yes 
-- but only if the declaration is significantly different, like has 
different argument types.

There's no single right answer for the declaration used in the C++ 
run-time support library.  My implementation might use "throw()", but 
yours might not have a throw-specifier at all, and both of us have 
correct implementations.  However, I do think it's reasonable to say 
that, independent of the declaration, this function can never throw an 
exception.  So, here's what I think:

1. The compiler's built-in declaration should include "throw()".  That 
will help us get good code when calling the function inside the 
compiler; the rest of the compiler will know no exceptions are leaving 
this function.

2. Ideally, the libstdc++ declaration should also use "throw()", and all 
callees should be "throw()", since that will generate the best code, and 
is the obvious right answer.

3. Ideally, the compiler should not warn when encountering a run-time 
library declaration doesn't include the "throw()".  (However, I think it 
would be OK to warn if it sees "throw (X)", even though that's less 
restrictive than no throw-specifier at all, as "throw (X)" indicates 
that somebody seems to think this function is actually going to throw an 
exception, which is weird.)

Note that if (1) and (2) are done, though, (3) can be a future project; 
it only affects other C++ library implementations, and we don't care so 
much about that.

Does that help?

--
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713