From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16246 invoked by alias); 28 Apr 2006 20:43:39 -0000 Received: (qmail 16228 invoked by uid 48); 28 Apr 2006 20:43:35 -0000 Date: Fri, 28 Apr 2006 20:43:00 -0000 Message-ID: <20060428204335.16227.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/msg02537.txt.bz2 List-Id: ------- Comment #4 from marc dot glisse at normalesup dot org 2006-04-28 20:43 ------- (In reply to comment #3) > Well, I think Andrew has a point: suppose we rename all those functions to > _M_cos and co. Then, later, we discover that a third libc (not Solaris, not > GNU) conflicts with those names too... The point is that there is no *robust* > concept of less-conflict prone name: I thought about a name that contains gcc or glibcxx or something like that, but now I understand Andrew's point, thank you. > if such conflicts happen then something is > wrong in the design, something profound is wrong, somewhere. So something is wrong in the design. If the wrong thing is in that the libc and compiler are separate entities, there is little we can do about it. So what can be done? Should all those private classes and functions be declared in some specific namespace std::glibcxx_private to have a single point of failure? The current names (__cos and similar) do conflict, and unless a better solution is proposed, renaming (and re-renaming if there still are problems) seems like the easy way to fix it. > We already > discussed this issue in another context (header guards names), and, not having > looked very closely into this specific issue, I'm pretty convinced. Convinced of what? (sorry about my slow understanding of these conversations, I am quite new to gcc, and I guess the style needs some time to sink in) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27340