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 [EMAIL PROTECTED] (650) 331-3385 x713
