[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Potential Mono removal from 32-bit big endian PowerPC in next upload



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


Reply to: