From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11315 invoked by alias); 25 Oct 2005 20:36:44 -0000 Mailing-List: contact java-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: java-prs-owner@gcc.gnu.org Received: (qmail 11293 invoked by uid 48); 25 Oct 2005 20:36:44 -0000 Date: Tue, 25 Oct 2005 20:36:00 -0000 Message-ID: <20051025203644.11292.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug libgcj/17021] libgcj verifier resolves classes too eagerly In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: java-prs@gcc.gnu.org From: "mckinlay at redhat dot com" X-SW-Source: 2005-q4/txt/msg00214.txt.bz2 List-Id: ------- Comment #14 from mckinlay at redhat dot com 2005-10-25 20:36 ------- Robert, thanks very much for working on this. Examining the behaviour of Sun's verifier a bit more shows that it does attempt to resolve classes where type compatibility can not be proven by a simple string comparison, so I think that your approach is correct. I have one pedantic concern about the implementation of _Jv_equalUtf8Const_classnames: Say we're comparing a class called "Lfoo" and one called "fool", and fool is given in the bytecode form while "Lfoo" is in the regular form. So, _Jv_equalUtf8Const_classnames would end up comparing the strings "Lfoo" and "Lfool;". Whats to stop it falsely returning true in this case? Also, how about a more concise name for this function: _Jv_equalUtf8Classnames? It will also need a ChangeLog entry, of course - other than these issues, this patch looks pretty good. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17021