[Mono-devel-list] Corlib test cases

[Bernie Solomon]

> > 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/BinaryRea
derTest.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

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.

Bernie

typedef struct
{
	union {
		guint32 ss32;
#if G_BYTE_ORDER != G_LITTLE_ENDIAN
	    struct {
		    unsigned int sign      : 1;
		    unsigned int reserved2 : 7;
		    unsigned int scale     : 8;
		    unsigned int reserved1 : 16;
	    } signscale;
#else
	    struct {
		    unsigned int reserved1 : 16;
		    unsigned int scale     : 8;
		    unsigned int reserved2 : 7;
		    unsigned int sign      : 1;
	    } signscale;
#endif
	} u;
    guint32 hi32;
    guint32 lo32;
    guint32 mid32;
} decimal_repr;