From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6521 invoked by alias); 21 Jan 2006 21:45:32 -0000 Received: (qmail 6491 invoked by alias); 21 Jan 2006 21:45:30 -0000 Date: Sat, 21 Jan 2006 21:45:00 -0000 Message-ID: <20060121214530.6490.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug c++/23628] Typeinfo comparison code easily breaks shared libs In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "gdr at cs dot tamu dot edu" 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-01/txt/msg02208.txt.bz2 List-Id: ------- Comment #27 from gdr at cs dot tamu dot edu 2006-01-21 21:45 ------- Subject: Re: Typeinfo comparison code easily breaks shared libs "rjohnson at dogstar-interactive dot com" writes: | I just got bit by this using | gcc version 4.0.3 20051201 (prerelease) (Debian 4.0.2-5) (powerpc) | | It's just my $.02 from the gallery, but that address comparison in the | type_info::oprator==() implementation looks suspect. Stroustrup (3rd edition, | $15.4.4) specifically says: | | It is _not_ guaranteed that there is only one type_info object for each type in | the system. | | and then he goes on to call out dynamically linked libraries as a particular | case. | | If folks are interested, I can propose a relatively inexpensive (i.e. | non-strcmp) runtime strawman for consideration. Please look more carefully at the real implementation and look up the archive. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23628