[Mono-devel-list] Corlib test cases

Bernie Solomon bernard at ugsolutions.com
Thu Jan 22 19:02:11 EST 2004

> > 17) MonoTests.System.IO.BinaryReaderTest.ReadDecimal : test#01
> > expected:<-18295873486192640>
> > but was:<18295873486192640>
> >
> > in [0x00043] (at
derTest.cs:977) MonoTests.System.IO.BinaryReaderTest:ReadDecimal ()
> Oh, this is an interesting one. If I run the following code on MS.NET I
> d is -18295873486192640
> d != -18295873486192640

This seems a good effort to me (when working on ports it was hard to know if
failures were due to the port or the class libraries as I didn't know what
expected results were without trying elsewhere too).

Sometime ago I actually did a little poking about on this as I didn't know
if it was my porting problem or not. In the runtime's header it has the
following - though I don't know how this was found. If you change this so
the sign is the whole byte (i.e. removed reserved2 and change sign) then the
behaviour is similar to what you say here - treating any non-zero value of
sign as -ve and you get the same value. But the actual byte stream seems
like a corrupt decimal. Whether behaviour on such streams should be
indentical is open to debate. However perhaps the fix is to make the test
use a cleaner version of the number. Or change the run-times handling of
sign to produce similar odd behaviour is another solution.


typedef struct
	union {
		guint32 ss32;
	    struct {
		    unsigned int sign      : 1;
		    unsigned int reserved2 : 7;
		    unsigned int scale     : 8;
		    unsigned int reserved1 : 16;
	    } signscale;
	    struct {
		    unsigned int reserved1 : 16;
		    unsigned int scale     : 8;
		    unsigned int reserved2 : 7;
		    unsigned int sign      : 1;
	    } signscale;
	} u;
    guint32 hi32;
    guint32 lo32;
    guint32 mid32;
} decimal_repr;

More information about the Mono-devel-list mailing list