From: schabi at logix-tt.com (Markus Schaber) Date: Fri, 22 Sep 2006 15:18:56 +0200 Subject: [Pljava-dev] readBytes() / writeBytes() In-Reply-To: <4513A3ED.3050401@tada.se> References: <4512F5E4.9060600@logix-tt.com> <45139C17.3050006@tada.se> <4513A107.4060809@logix-tt.com> <4513A3ED.3050401@tada.se> Message-ID: <4513E2C0.3050804@logix-tt.com> Hi, Thomas, Thomas Hallgren wrote: > AFAIK, they all start with a 4 byte header denoting the length. So > your mapping starts by doing a readInt() and then you base the rest > on that. From my tests, that 4 byte header is cut of, the SQLInput starts at the first "real" data byte. >> As it looks now, my only possibility seems to find out the native >> endianness of the machine, and then read the data byte-for-byte via >> readByte(), and then put it together for myself. Most of the code >> should be copyable from the WKB parsers I've already written, so no >> real effort, but I'm still afraid that calling a native function >> per byte will not perform best. >> > You should not bother with endianess. The implementation deals with > that. At leas on my machine (i386 architecture), the doubles I read in get scrambled when using readDouble(). However, when I swap the bytes, I get the correct results. From looking at the code, readDouble() & co seem to assume network byte order, instead of using the native endianness of the machine. But for reading PostGIS geometry data, I've to parse the native format, as that is what the C code uses. So I will resort to read byte-for-byte. Thanks for your patience, Markus -- Markus Schaber | Logical Tracking&Tracing International AG Dipl. Inf. | Software Development GIS Fight against software patents in Europe! www.ffii.org www.nosoftwarepatents.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature URL: