From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10245 invoked by alias); 21 Jun 2010 15:41:31 -0000 Received: (qmail 10182 invoked by uid 48); 21 Jun 2010 15:41:20 -0000 Date: Mon, 21 Jun 2010 15:41:00 -0000 Message-ID: <20100621154120.10181.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug libstdc++/44611] Including and hides ::signbit function In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "paolo dot carlini at oracle dot com" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2010-06/txt/msg02058.txt.bz2 ------- 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 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 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 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