Re: Analysis of Mauve failures - Part 1

[Eric Blake <ebb9 at email dot byu dot edu>]

Some comments on the classes I have touched (mainly on the Classpath
side) in the past two months:

Mark Wielaard wrote:
> 
> Skipping analysis of Character failures (seem to be about 80) since Eric
> has recently rewritten Character support for Unicode 3.0 and the tests
> seem to be written for an older Unicode version. Probably needs a
> rewrite of the Mauve tests.

Yes, I think Mauve needs to be updated here.  Unfortunately, I have not
yet taken the time to look into doing that.

> > FAIL: gnu.testlet.java.lang.Double.DoubleTest: Error: test_toString failed - 8 (number 1)
> > FAIL: gnu.testlet.java.lang.Double.DoubleTest: Error: test_equals failed CYGNUS: Double.equals - 8 (number 1)
> > FAIL: gnu.testlet.java.lang.Double.DoubleTest: Error: test_intValue returned wrong results CYGNUS: Float to int conversions - 1 (number 1)
> > FAIL: gnu.testlet.java.lang.Double.DoubleTest: Error: test_longValue returned wrong results CYGNUS: Float to int conversions - 1 (number 1)
> Don't know what is going on here. If I run these by hand they succeed!?!

I haven't touched string conversion in Classpath, so I doubt a merge
would solve this. I do know that the string->float conversion in
Classpath is wrong, since it uses string->double->float which can have
off-by-ulp errors (I know this, because I had to fix this very sort of
bug for the jikes compiler).

> 
> > FAIL: gnu.testlet.java.lang.Integer.getInteger (number 12)
> Fixed by recent patch on branch. Another fix is in Classpath which
> should go to the trunk.
> 
> > FAIL: gnu.testlet.java.lang.Integer.getInteger (number 17)
> Integer.getInteger(null) throws NullPointerException. Believed fixed in
> Classpath.
...
> All fixed by recent patches on branch. Believed to be also fixed in
> Classpath. Wrapper classes should be merged for 3.2.

Yes, I believe these are fixed in classpath. I'm happy to help with the
3.2 merge, when the time is right.

> 
> > FAIL: gnu.testlet.java.lang.String.CASE_INSENSITIVE_ORDER: unicode mappings (number 1)
> > FAIL: gnu.testlet.java.lang.String.CASE_INSENSITIVE_ORDER: unicode mappings (number 2)
> The source says: "These two tests are unspecified - see Sun bug 4425387"

Well, since I wrote that comment, Sun went ahead and specified the
behavior of CASE_INSENSITIVE_ORDER. I ought to update that test to match
my proposed patch for String (the one that Tom has put on the back
burner for a while).

> 
> > FAIL: gnu.testlet.java.lang.reflect.Modifier.toString12 (number 1)
> > FAIL: gnu.testlet.java.lang.reflect.Modifier.toString12 (number 2)
> Test expects Modifier.STRICT to be represented by the String "strict",
> we return "strictfp" which seems correct to me.

Yes, it looks like that test is wrong.

> 
> OK. That is it for now. Going to get some sleep. Analysis of the other
> ~60 failures will come later.

Thanks for looking into this!

> 
> Cheers,
> 
> Mark
> 
> P.S. My machine seems to be unable to reach gcc.gnu.org although I do
> get some messages from the mailinglist I seem to be unable to send them
> at the moment. We will see if this reaches the list.

-- 
This signature intentionally left boring.

Eric Blake             ebb9@email.byu.edu
  BYU student, free software programmer