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. We could bump the protocol number, but I notice that that has never been done, even when the format of the position message changed :) That would mean that people running plib FlightGear wouldn't see new clients, which is probably unacceptable. 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
