Tim Moore wrote: > Stuart Buchanan wrote: >> Csaba Halász wrote: >> >>> On 32 bit system, sizeof(T_PositionMsg) = 196. On 64 bit system it is >>> 200, due to extra 4 bytes padding at the end. >>> >>> To make matters worse, in the assembled MP packet this message is >>> followed by property values. >>> Assuming the padding bytes are zero, a 32 bit receiver should be able >>> to process packets sent by a 64 bit machine, because it skips over the >>> unknown id of 0. I am puzzled how it even works the other way around. >>> >>> I also don't understand the reason for the padding. > The xdr_data2_t elements are 8 bytes long and must be 8-byte aligned on > x86_64; > see http://refspecs.freestandards.org/elf/x86_64-abi-0.95.pdf . Therefore the > whole structure must be 8 byte aligned. >> It's been years since I looked at the MP code, but IIRC the XDR spec requires >> padding so that each value is a multiple of 4 bytes in length. I remember >> having >> to put in some code to add padding when writing string values for the MP chat >> function. It's entirely possible that there's an ancient bug lurking there. > > The bug was introduced when the message format was changed to support > optional > properties. It's in the plib-based release too. > > This is a serious bug, definitely worth fixing. To make it more interesting, > the > padding inserted on x86_64 could contain garbage that makes it look like a > real > property. As I see it, the best plan is to add the padding to the structure > and > explicitly zero the padding. Then, add some defensive code to see if the > padding > in a received message is 0; if it is not, then verify that the property list > is > well-formed if we start decoding from that word. If it isn't, then assume > that > the message was sent by an old 64 bit client with properties starting 200 > bytes > after the beginning of the position message. I've checked in a fix that changes the message size and should decrypt messages from old FG copies.
Tim ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
