From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 763 invoked by alias); 19 Jan 2003 23:40:39 -0000 Mailing-List: contact mauve-discuss-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: mauve-discuss-owner@sources.redhat.com Received: (qmail 626 invoked from network); 19 Jan 2003 23:40:38 -0000 Received: from unknown (HELO piglet.dstc.edu.au) (130.102.176.1) by 172.16.49.205 with SMTP; 19 Jan 2003 23:40:38 -0000 Received: from dstc.edu.au (soluble.dstc.edu.au [130.102.176.43]) by piglet.dstc.edu.au (8.12.3/8.12.3) with ESMTP id h0JNdufh022135; Mon, 20 Jan 2003 09:39:56 +1000 (EST) Message-Id: <200301192339.h0JNdufh022135@piglet.dstc.edu.au> To: Mark Wielaard cc: Dalibor Topic , Anthony Green , mauve-discuss@sources.redhat.com, crawley@piglet.dstc.edu.au Subject: Re: 600+ BigDecimal tests In-Reply-To: Message from Mark Wielaard of "18 Jan 2003 17:04:37 +0100." <1042905877.24536.344.camel@elsschot> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 19 Jan 2003 23:40:00 -0000 From: Stephen Crawley X-Virus-Scanned: Message: ok X-Scanned-By: MIMEDefang 2.9 (www dot roaringpenguin dot com slash mimedefang) X-SW-Source: 2003-q1/txt/msg00004.txt.bz2 Folks, I've been looking at DiagBigDecimal and the "bugs" that it shows up. Some are genuine, but some are questionable. (The following is from memory ... YMMV) * There is a bug with the parse methods barffing with a "+" in the exponent in strings like "123.4E+5". I think this is the bug that Mark has patched. * There is a bug in the toString() method that doesn't add a leading zero in some cases; e.g. it produces ".1234" instead of "0.1234". I have a fix for this. [I'll submit it tonight.] * Some of the other tests check exception message strings, and are failing because the messages are different. I don't know whether this is a bug or not. Is Classpath aiming to give the same exception messages as the Sun JDK implementation ??? * The 'has001' failure is due to differences in the way that Classpath and the SUN JDK are calculating hashcodes. I don't know whether this is a bug or not. Is Classpath aiming to give the same hash code values as the Sun JDK implementation ??? -- Steve