[Mono-devel-list] Corlib test cases

[David Sheldon]

On Thu, Jan 22, 2004 at 10:05:10PM +0000, David Sheldon wrote:
> I have been trying to assign bug numbers to the tests that I can see
> failing. 

Here are my notes on the next 10. There are some interesting ones here
that I cannot duplicate outside of the test case framework (yet they
happen every time I run the tests), and some that I just don't really
understand.

David

> 11) MonoTests.System.DoubleFormatterTest.TestFormatStringsN1 : DblFn1 #7 
> 	String lengths are both 78.
> 	Strings differ at index 13.
> 	
> 	expected:<"99.999,99999960000000000000000000000000000000000...">
> 	 but was:<"99.999,99999959998400000000000000000000000000000...">
> 	-----------------------^
> 	
>                       
> in [0x0000d] (at /home/sheldon/hacking/mono/raw_cvs/mcs/class/corlib/Test/System/DoubleFormatterTest.cs:51) MonoTests.System.DoubleFormatterTest:FormatStringTest (string,System.Globalization.NumberFormatInfo,double,string,string)
> in [0x000fa] (at /home/sheldon/hacking/mono/raw_cvs/mcs/class/corlib/Test/System/DoubleFormatterTest.cs:138) MonoTests.System.DoubleFormatterTest:TestFormatStringsN1 ()

> 12) MonoTests.System.DoubleFormatterTest.TestFormatStringsN2 : DblFn2 #6 
> 	String lengths are both 17.
> 	Strings differ at index 13.
> 	
> 	expected:<"99,999.999999600$">
> 	 but was:<"99,999.999999599$">
> 	-----------------------^

Do we use less accurate Doubles or something? These look like a floating-point
accuracy bug. 


> 13) MonoTests.System.DoubleTest.TestToString : ToString Failed: '1.2' Should be "1.2" with "#.##" 
> 	String lengths differ.  Expected length=3, but was length=4.
> 	Strings differ at index 2.
> 	
> 	expected:<"1.2">
> 	 but was:<"1.19">
> 	------------^
>                       
> in [0x01414] (at /home/sheldon/hacking/mono/raw_cvs/mcs/class/corlib/Test/System/DoubleTest.cs:443) MonoTests.System.DoubleTest:CustomFormatHelper ()
> in [0x00050] (at /home/sheldon/hacking/mono/raw_cvs/mcs/class/corlib/Test/System/DoubleTest.cs:221) MonoTests.System.DoubleTest:TestToString ()

> 14) MonoTests.System.FloatingPointFormatterTest.Format1 : F2 
> 	String lengths differ.  Expected length=5, but was length=16.
> 	Strings differ at index 1.
> 	
> 	expected:<"1E+15">
> 	 but was:<"1000000000000000">
> 	-----------^
> 	
>                       
> in [0x0003b] (at /home/sheldon/hacking/mono/raw_cvs/mcs/class/corlib/Test/System/FloatingPointFormatterTest.cs:23) MonoTests.System.FloatingPointFormatterTest:Format1 ()

Hmm. I cannot duplicate these problems in stand-alone code, so I cannot narrow
the problem down any further.


> 15) MonoTests.System.Int32Test.TestToString : #D06(3) 
> 	String lengths differ.  Expected length=14, but was length=12.
> 	Strings differ at index 12.
> 	
> 	expected:<"-2147483648.00">
> 	 but was:<"-2147483648.">
> 	----------------------^
> 	
>                       
> in [0x0014b] (at /home/sheldon/hacking/mono/raw_cvs/mcs/class/corlib/Test/System/Int32Test.cs:212) MonoTests.System.Int32Test:TestToString ()

> 16) MonoTests.System.Int64Test.TestToString : MyInt64_2.ToString(Formats1[3]) 
> 	String lengths differ.  Expected length=23, but was length=21.
> 	Strings differ at index 21.
> 	
> 	expected:<"-9223372036854775808.00">
> 	 but was:<"-9223372036854775808.">
> 	-------------------------------^
> 	
>                       
> in [0x00108] (at /home/sheldon/hacking/mono/raw_cvs/mcs/class/corlib/Test/System/Int64Test.cs:300) MonoTests.System.Int64Test:TestToString ()

More of the Culture problems in bug 53022.

> 17) MonoTests.System.IO.BinaryReaderTest.ReadDecimal : test#01 
> 	expected:<-18295873486192640>
> 	 but was:<18295873486192640>
>                           
> in [0x00043] (at /home/sheldon/hacking/mono/raw_cvs/mcs/class/corlib/Test/System.IO/BinaryReaderTest.cs:977) MonoTests.System.IO.BinaryReaderTest:ReadDecimal ()

Oh, this is an interesting one. If I run the following code on MS.NET I get: 

d is -18295873486192640
d != -18295873486192640

If I run it on mono I get:

d is 18295873486192640
d != -18295873486192640

So there is definitely a difference, but it reveals that there might be a more
fundamental problem with the test case.

The code is: 

using System;                                                                   
using System.IO;
 
namespace p {                                                                   
   public class m {                                                             
                                                                                
      public static void Main (string [] args) {
	        MemoryStream stream = null;
                BinaryReader reader = null;
                try {
                        stream = new MemoryStream (new byte [] {0, 0, 0, 0, 0, 0, 65, 0, 0, 0, 0, 0, 0, 0, 0 ,87, 98, 0, 0, 0, 0});
                        reader = new BinaryReader (stream);
   
                        Decimal d = reader.ReadDecimal();
                        Console.WriteLine("d is " + d);
                        if (d != -18295873486192640) {
                           Console.WriteLine("d != -18295873486192640");
			}
                } finally {
                        reader.Close ();
                        stream.Close ();
                }    

}                                                                         
   }                                                                            
}                                          


> 18) MonoTests.System.IO.BufferedStreamTest.CtorOutOfRangeException2 : ObjectDisposedException was expected

For this one (constructing a BufferedStream from a closed stream), we don't
throw the exception on construction, but on the first read, as we do not read
from the underlying stream in the constructor. 

If we want to throw the ObjectDisposedException in the constructor, then we
will need to change the way that buffering happens. Is this something important
to solve, or should we remove the test?


> 19) MonoTests.System.IO.FileInfoTest.OpenReadIOException : IOException was expected

I don't really understand this I'm afraid. It seems that on windows you cannot
open the file both to get info and to read it, or something. Is this a locking
test? Is it desirable to throw the exception that is expected?


-- 
"There is no statute of limitations on stupidity."
-- Randomly produced by a computer program called Markov3.