Re: Re: [Oledb-dev] double precision error with pg linux server, but not with windows pg server
От | Martijn van Oosterhout |
---|---|
Тема | Re: Re: [Oledb-dev] double precision error with pg linux server, but not with windows pg server |
Дата | |
Msg-id | 20070522065546.GA32658@svana.org обсуждение исходный текст |
Ответ на | Re: Re: [Oledb-dev] double precision error with pg linux server, but not with windows pg server (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On Mon, May 21, 2007 at 11:58:35PM -0400, Tom Lane wrote: > The intent of the FP binary I/O code we have is that for platforms > supporting IEEE-compliant FP formats, the on-the-wire representation > should be uniformly big-endian, same as is true for integers. So > I would concur with a patch that ensures that this is what happens > on the different ARM variants ... though I'll still be interested > to see how you make that happen given the rather poor visibility > into which model and endianness we are running on. Well, I have an idea how you might do this: figure out the ordering of the float at runtime. You can easily construct a float with any given bit pattern. You can then examine the bytes to determine the order and build a mapping table to reorder them. The program below creates a float with the bit pattern 01020304. You can then examine the bits of the float to determine the rearranging needed. You could do the same for 64-bit floats. This is obviously only needed for systems where the order can't be determined at compile time. ldexp is in SVr4, 4.3BSD and C89. #include <stdio.h> #include <math.h> int main() { float f = ldexp(1.0,-119) + ldexp(1.0,-125) + ldexp(1.0,-126) + ldexp(1.0,-133) + ldexp(1.0,-142); unsigned char *a= (char*)&f; printf("Float: %g, char: %02x%02X%02X%02X\n", f, a[0], a[1], a[2], a[3]); } Have a nice day, -- Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/ > From each according to his ability. To each according to his ability to litigate.
В списке pgsql-hackers по дате отправления: