From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21286 invoked by alias); 28 Apr 2006 21:57:18 -0000 Received: (qmail 21261 invoked by uid 48); 28 Apr 2006 21:57:14 -0000 Date: Fri, 28 Apr 2006 21:57:00 -0000 Message-ID: <20060428215714.21260.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug libstdc++/27340] valarray uses __cos which may conflict with libm functions In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "marc dot glisse at normalesup dot org" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2006-04/txt/msg02540.txt.bz2 List-Id: ------- Comment #6 from marc dot glisse at normalesup dot org 2006-04-28 21:57 ------- (In reply to comment #4) > Should all those private classes and functions be declared in some > specific namespace std::glibcxx_private to have a single point of failure? Oups, I just noticed that was one of the roles of __gnu_cxx (although I don't understand why this namespace is not a subnamespace of std:: as tr1 (or at least contains a using namespace std;), which would at the same time fix things like getenv not being prefixed by std:: in ext/mt_allocator.h). So in this case it would seem reasonable to move the classes to that namespace. (In reply to comment #5) > Again, I > encourage you to post on the libstdc++ list a careful analysis of the issue, > complete of mini-patch (fixing only one header, for example). At this point > what you mean by "playing around" is not at all clear. I had posted this bug report because I found it quite independant from the rest. It is easy to see on solaris that __cplusplus>=199711L declares a function __cos in namespace std, and I think I read somewhere that changing tha value of __cplusplus was being considered. I will eventually post something on the libstdc++ mailing list, but I am slowed down by several things: - I have only limited access to solaris 8 and 9, and several things would require solaris 10 to work properly (at least it would be less work) - the _GLIBCPP_USE_NAMESPACES in glibc has dozens of bugs (besides design issues), to the point that doing: namespace std { #include } actually works better than defining the macro right now... - tracking why and where all the macros like __USE_GNU are defined is a nightmare - it may not be possible to work on each header independantly, because headers include other headers But I haven't quite given up hope yet. Depends how much time I will get to work on this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27340