From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29293 invoked by alias); 28 Apr 2006 20:01:52 -0000 Received: (qmail 28908 invoked by uid 48); 28 Apr 2006 20:01:49 -0000 Date: Fri, 28 Apr 2006 20:01:00 -0000 Message-ID: <20060428200149.28907.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: "pcarlini at suse dot de" 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/msg02535.txt.bz2 List-Id: ------- Comment #3 from pcarlini at suse dot de 2006-04-28 20:01 ------- (In reply to comment #2) > (In reply to comment #1) > > Both libc and libstdc++ are considered part of the implementation which means > > both are valid to use this name space. > > Which means both should take care not to use a name (in this name space) > already used by the other one. I actually don't understand what your point is. 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: if such conflicts happen then something is wrong in the design, something profound is wrong, somewhere. 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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27340