------- Comment #7 from paolo dot carlini at oracle dot com 2008-07-09 11:13 ------- (In reply to comment #6) > Subject: Re: Simple std::bind use causes warnings with -Wextra > > paolo dot carlini at oracle dot com wrote: > > > Thanks Tom. In fact, yesterday I was writing without remembering my past > > analyses of this type of issue, with system header warnings not suppressed: > > TREE_NO_WARNING is *not* generically uses for that. Everything boils down to > > DECL_IN_SYSTEM_HEADER on the decl instead. > > Why is it reasonable for a libstdc++ header to return a cv-qualified > type, but not for user code to do so? > > In general, the system-header hack is to work around things we don't > control; we need to accept weird code in <stdio.h> because the OS > distributor controls that, not us. But, if it's not practical for > libstdc++ to avoid this warning, then it's probably not practical for > users to avoid it either, so then I wonder how beneficial the warning > is. On the other hand, I'd expect that libstdc++ could just avoid the > warning, by using a traits class to strip the cv-qualifier?
I'm sorry Mark, I'm not sure to understand. We are working under the assumption (result of past discussions) that, in general, we do want to warn for return types which are CV-qualified void and builtin types. Ok. Now, we can certainly make the library a tad more complex and strip those CV-qualifiers. Probably we'll do that, anyway, I'd like to ear Doug, the original author, about it. On the other hand, we have the #pragma for system headers which is currently able to suppress *any* warning besides this one, having to do with return types. Seems a separate question to me. It looks to me that the pragma should suppress this warning too. Do you agree? A final remark: for better and worse, our library is not currently -Wsystem-headers clean, not only because we don't have control over the underlying C library (that makes for a separate issue, rather annoying sometimes) but also for other reasons, for example, at times, suppressing any possible false positive would make the code much more complex (and I think we all agree that we absolutely want to avoid warnings from inside the headers), uncertainty about whether we do want a warning or not (e.g., the library would not warn if a core DR is implemented), etc. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36760
