From: thomas at tada.se (Thomas Hallgren)
Date: Fri, 22 Sep 2006 15:29:15 +0200
Subject: [Pljava-dev] readBytes() / writeBytes()
In-Reply-To: <4513E2C0.3050804@logix-tt.com>
References: <4512F5E4.9060600@logix-tt.com>	<45139C17.3050006@tada.se>
	<4513A107.4060809@logix-tt.com>	<4513A3ED.3050401@tada.se>
	<4513E2C0.3050804@logix-tt.com>
Message-ID: <4513E52B.5080108@tada.se>

Hi Markus,
I should have checked before I spoke. I see now that the implementation 
is incorrect. The intended functionality should of course be that the 4 
byte integer is intact when present and that all endianness is taken 
care of. This is a bug of course and I'll fix that eventually. Sorry for 
the confusion.

Regards,
Thomas Hallgren

Markus Schaber wrote:
> 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
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> Pljava-dev mailing list
> Pljava-dev at gborg.postgresql.org
> http://gborg.postgresql.org/mailman/listinfo/pljava-dev
>