On Mon, Mar 6, 2017 at 10:44 AM, Jonathan Wakely <jwakely.gcc@xxxxxxxxx> wrote: > It's not the case that most are there, for <cmath> it's around a third > of them (e.g. it declares three overloads of std::sin but only one of > the three is also in the global namespace). Fair enough. Then the perception is maybe even less accurate (but still there). >> Alternatively, I wonder if gcc could warn for this? Presumably the >> compiler will be aware that I am calling a function that was >> "indirectly" declared in a C-library header, and therefore outside the >> realm of standard-controlled behaviour? I don't know how hard that >> would be to achieve, just wonder if it's a possibility. > > I think the compiler would have to have special cases for every > function. I don't think your heuristic would work, because if you > #include <stdlib.h> and call ::abs then it's still declared in a > C-library header but there's no problem and no need to warn in that > case. But in that case the compiler could figure out that stdlib.h was included "directly" from user code, rather than "indirectly" being included by a libstdc++ header. So the rule would be something like this: if we're compiling C++, and the function was declared in a C-library foo.h, and the *only* #include <foo.h> (or #include_next <foo.h>) directives in this TU are in lines from headers on the libstdc++ default search path, then the user code never explicitly asked for foo.h and we should warn. Does that work in theory...?
