On Wed, Aug 26, 2015 at 05:28:28PM +0100, Jo Shields wrote:
>
>
> On 26/08/15 17:16, Lennart Sorensen wrote:
> >
> > And a patch that fixes that (since the double's stored in the table are
> > little endian, they have to be endian swapped before being returned as
> > a double).
> >
> > diff --git a/mscorlib/system/globalization/charunicodeinfo.cs
> > b/mscorlib/system/globalization/charunicodeinfo.cs
> > index 22a4a01..c8e2ce1 100644
> > --- a/mscorlib/system/globalization/charunicodeinfo.cs
> > +++ b/mscorlib/system/globalization/charunicodeinfo.cs
> > @@ -157,6 +157,22 @@ namespace System.Globalization {
> > return(value);
> > }
> >
> > + unsafe private static double EndianSwap(double value)
> > + {
> > + if (!BitConverter.IsLittleEndian) {
> > + byte *ptr = (byte *) &value;
> > + double res;
> > + byte *buf = (byte *) &res;
> > + ushort t = sizeof(double) - 1;
> > +
> > + for (ushort i = 0; i < sizeof(double); i++)
> > + buf[t-i] = ptr[i];
> > +
> > + return(res);
> > + } else
> > + return(value);
> > + }
> > +
> >
> > //We need to allocate the underlying table that provides us with
> > the information that we
> > //use. We allocate this once in the class initializer and then we
> > don't need to worry
> > @@ -322,7 +338,7 @@ namespace System.Globalization {
> > }
> > return (((double*)s_pNumericValues)[pBytePtr[(ch & 0x000f)]]);
> > #else
> > - return (((double*)s_pNumericValues)[pBytePtr[(ch & 0x000f)]]);
> > + return EndianSwap(((double*)s_pNumericValues)[pBytePtr[(ch &
> > 0x000f)]]);
> > #endif
> > }
>
> This looks like it belongs alongside the endianness fixes in
> charunicodeinfo.cs from 41a6d3d6a5432b964b6f8439b6375ffad6f2e6cb? I'll
> point the s390x porter (who's the primary big-endian guy) at your message
Yes that looks very much like it was a small missed part there. I was
actually puzzled when I found it, that the indexes were all correctly
endianess fixed, but the data returned was not.
--
Len Sorensen
