------- Comment #6 from paolo dot carlini at oracle dot com 2010-06-21 15:41 ------- To be honest, I have zero doubts about nullptr_t: nowhere 18.2 hints at providing it in the global namespace, per se.
About signbit, if it's a macro in C it has to be undefined in order to implement the <cmath> facility in c++0x, see 26.8/11. Really, I don't see how the macro and the template can co-exist: "The templates defined in <cmath> replace the C macros with the same names" and the templates are specified in namespace std. If, on the other hand, we are talking in general about the *.h headers, the basic point of DR456, finally resolved, is that those headers very often come together with the C library, over which many C++ library implementations have ***no control*** today (maybe back in the C++98 times people have some other ideas about the interaction between C and C++ in typical platforms, I don't know) Irrespective of the details of the resolution, that is the very important gist of the resolution: implementors of the C++ library are supposed to not have controls on the internals of the *.h C headers and for sure are not supposed to add in facilities. If, in corner cases (*), that is still not clear enough, maybe (other members of) the LWG can further clarify the matter, but it's clear enough for me ;) (*) In the past, we had one, that with memchr & co, which has been resolved by Jakub at the C headers level because <cstring> could not be implemented correctly otherwise. At some point I wanted to raise the issue in the LWG, because, missing an ISO clarification, we forced in a glibc + v3 solution which is contrary to the gist of 456. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44611
