[sldev] Endian bug in 1.15.0.2 message template reader?

[Phoenix]

On 2007 May 13, at 17:14, Paul TBBle Hampson wrote:
...<snip>
> The message template for ParcelOverlay is:
>
> // ParcelOverlay
> // We send N packets per region to the viewer.
> // N = 4, currently.  At 256x256 meter regions, 4x4 meter parcel grid,
> // there are 4096 parcel units per region.  At N = 4, that's 1024  
> units
> // per packet, allowing 8 bit bytes.
> // sim -> viewer
> // reliable
> {
>     ParcelOverlay Low Trusted Zerocoded
>     {
>         ParcelData      Single
>         {   SequenceID  S32             }   // 0...3, which piece  
> of region
>         {   Data        Variable    2   }   // packed bit-field,  
> (grids*grids)/N
>     }
> }
>
> I guess my first question is, what's that '2' mean? It seems to be
> defined as 'size' during the template reading process, but I've not
> yet been able to work out what it's used for... I'm _hoping_ it turns
> out to be "size will be encoded in a 16-bit word" in which case the
> fix will be as easy as "find the code that reads the size off the
> network, and byteswap it if it's reading anything longer than 1".

The 2 there means that two bytes are used to describe the length of  
the block. From what I can tell by scanning the code  
(lltemplatemessagereader.cpp in decodeData()) we rely on htonmemcpy()  
to copy the size as a U16. In htonmemcpy() in message.h, it will fall  
into the correct byte flip for U16 if LL_BIG_ENDIAN has been defined  
on your platform. That compiler directive is defined in llcommon/ 
llpreprocessor.h on linux if <endian.h> did not define  
__LITTLE_ENDIAN__.

Since 1.15.0.2 works fine on my G5, I suspect a misconfiguration in  
your build environment, but if you find anything wrong in linden code  
in that area please let us know so it can be corrected.


> I guess this also assumes that the SL network protocol is little- 
> endian.

We _should_ be using network byte order everywhere.


> Given that Mac OS X runs on PowerPC too, I figured there'd be some
> byteswapping logic for it, but I couldn't find any relevant defines
> in llmessage's source.


As noted above, most of the byte ordering happens in llmessage.h  
htonmemcpy().

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070514/ee10eb20/PGP.pgp