Re: [Flightgear-devel] net_fdm.hxx net_ctrls.hxx
I thought you were simply looking for code portability. You must never send a binary stucture across a network. Even if you get the sizes correct, you'll have endian problems when running different architectures (PC vs Mac). You must manually ship the data bytes in a defined order and reconstruct it at the other end. At that point, it doesn't matter what the padding or for different compilers (or the order) is because you won't be sending the padding - just the data. Never block transfer a structure by providing a pointer and size, there is simply no way for that to work cross-platform. Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] net_fdm.hxx net_ctrls.hxx
So the data should include a flag to tell what endian form it is, and the code should be written to support both ways? Image file formats specify and endianness in the specification, not the files. If it's in the files, then you'd need code to handle both ways... On Sun, 2005-03-27 at 09:28 -0500, Norman Vine wrote: Paul Kahler writes: Never block transfer a structure by providing a pointer and size, there is simply no way for that to work cross-platform. Please That this isn't true is amply demonstrated by all the images that get passed around the net :-) All one needs to do is make sure that the endian order of the data is well defined ! There are many ways to do this perhaps the easiest is to just use a 'magic' cookie at the beginning of the data structure *or* have a well defined structure that insures a certain endian order is imposed on the creator. Cheers Norman ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] net_fdm.hxx net_ctrls.hxx
Don't ever assume that all the components of a structure will be at the same location within the struct on all architectures, or that the structure size will be the same. Processor architecture, language used, compiler, and compiler flags all can change how a structure is packed. That usually means that when an element of your structure is less than the word size of the machine, it'll start the next element of the structure at the next word boundary. So if you have a char followed by an int on a 32 bit machine, your compiler can decide to put the int 3 bytes after the char, instead of immediately following it. Sometimes you can change how things are packed by using compiler specific pragmas. Sometimes you cannot. - Miles -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Norman Vine Sent: Sunday, March 27, 2005 9:29 AM To: FlightGear developers discussions Subject: RE: [Flightgear-devel] net_fdm.hxx net_ctrls.hxx Paul Kahler writes: Never block transfer a structure by providing a pointer and size, there is simply no way for that to work cross-platform. Please That this isn't true is amply demonstrated by all the images that get passed around the net :-) All one needs to do is make sure that the endian order of the data is well defined ! There are many ways to do this perhaps the easiest is to just use a 'magic' cookie at the beginning of the data structure *or* have a well defined structure that insures a certain endian order is imposed on the creator. Cheers Norman ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] net_fdm.hxx net_ctrls.hxx
On Mar 27, 2005, at 3:20 PM, Miles Gazic wrote: Don't ever assume that all the components of a structure will be at the same location within the struct on all architectures, or that the structure size will be the same. Processor architecture, language used, compiler, and compiler flags all can change how a structure is packed. That usually means that when an element of your structure is less than the word size of the machine, it'll start the next element of the structure at the next word boundary. So if you have a char followed by an int on a 32 bit machine, your compiler can decide to put the int 3 bytes after the char, instead of immediately following it. Sometimes you can change how things are packed by using compiler specific pragmas. Sometimes you cannot. - Miles Excellent point however a responsable programmer can take this into account when designing the data structures and account for this. Again I point out the myriad of image formats that demonstrate that you can successfully pass structures over the Net. Cheers Norman -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Norman Vine Sent: Sunday, March 27, 2005 9:29 AM To: FlightGear developers discussions Subject: RE: [Flightgear-devel] net_fdm.hxx net_ctrls.hxx Paul Kahler writes: Never block transfer a structure by providing a pointer and size, there is simply no way for that to work cross-platform. Please That this isn't true is amply demonstrated by all the images that get passed around the net :-) All one needs to do is make sure that the endian order of the data is well defined ! There are many ways to do this perhaps the easiest is to just use a 'magic' cookie at the beginning of the data structure *or* have a well defined structure that insures a certain endian order is imposed on the creator. Cheers Norman ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] net_fdm.hxx net_ctrls.hxx
Curtis L. Olson wrote: Erik Hofman wrote: Andy Ross wrote: The fact that this is an apple header implies that it ought to work out of the box on OS/X and the various BSDs. The only other platforms we support right now are SGI and Solaris, right? Can anyone check the status of stdint.h on those platforms? SGI: present and supported. Ok, I'm going to commit some changes to the net_fdm.hxx, net_ctrls.hxx, and net_gui.hxx files. I bumped up the embedded version number. I *think* I took care of all the details, but there's always a chance I missed something. Let me know right away if any one has problems. Hmmm, I see write away that even if I use int8_t or int16_t, they still get padded out to 4 bytes in the structure that is sent across the net (on 32bit Linux.) Does that mean we always want to use int32_t to avoid potential confusion, or is this situation ok? There are two issues here: 1. Resolving ambiguity in the length of data types across different platforms and architectures such as int, time_t, bool, etc. (Now fixed.) 2. Resolving ambiguity in how different platforms/architectures pack/pad the data structures. (Is this still a problem?) Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] net_fdm.hxx net_ctrls.hxx
Curtis L. Olson wrote:
Hmmm, I see write away that even if I use int8_t or int16_t, they still
get padded out to 4 bytes in the structure that is sent across the net
(on 32bit Linux.) Does that mean we always want to use int32_t to avoid
potential confusion, or is this situation ok?
Most compilers have a set of switches you can use to control structure
padding and alignment. But indeed, there's nothing in the spec that
says what the proper alignment should be.
FWIW, every compiler I know stores each element in order, and pads it
up to its natural alignment. So this struct takes 8 bytes in memory
on all platforms I know:
struct { int8_t a; int8_t b; int32_t c; }
But this one takes at least 12 (word-size padding is added at the end
on most or all compiler):
struct { int8_t a; int32_t b; int8_t c; }
So long as the structure honors those rules, you should be more or
less portable. Other options are, obviously, to store everything as a
int32_t and do the bit packing yourself. You'll need to do this in
any case if you want endian compatibility. This is one of the many
reasons that dumping structures from memory to I/O is considered
problematic. :)
Andy
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] net_fdm.hxx net_ctrls.hxx
Curtis L. Olson wrote: I'd like to take a whack at making the FGNetFDM and FGNetCTRLS structures more portable across platforms and OS's. There are some serious problems right now going between 32 and 64 bit architectures. There are other minor problems going between different OS's. Yeah, that would be great. It's best to avoid structs completely for that though. I see that Linux (C99) has an inttypes.h include that defines | ||int8_t, int16_t, int32_t, int64_t and ||uint8_t, uint16_t, uint32_t, uint64_t | |Using these instead of things like bool, int, and time_t could go a *long* ways toward removing ambiguity in the sizes of these across different platforms and architectures.| || Can anyone confirm or deny if this or something close to it exists in MSVC? I believe all the modern unix based platforms should have this already, but windows sometimes blazes it's own trail ... :-) I think almost all modern compilers define these one way or another. If not it would be possible to define them for these compilers ourselves. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] net_fdm.hxx net_ctrls.hxx
Curtis L. Olson wrote : I'd like to take a whack at making the FGNetFDM and FGNetCTRLS structures more portable across platforms and OS's. There are some serious problems right now going between 32 and 64 bit architectures. There are other minor problems going between different OS's. I see that Linux (C99) has an inttypes.h include that defines | ||int8_t, int16_t, int32_t, int64_t and ||uint8_t, uint16_t, uint32_t, uint64_t | |Using these instead of things like bool, int, and time_t could go a *long* ways toward removing ambiguity in the sizes of these across different platforms and architectures.| || Can anyone confirm or deny if this or something close to it exists in MSVC? I believe all the modern unix based platforms should have this already, but windows sometimes blazes it's own trail ... :-) These types are not defined, instead it has something like this : typedef signed char INT8, *PINT8; typedef signed shortINT16, *PINT16; typedef signed int INT32, *PINT32; typedef signed __int64 INT64, *PINT64; typedef unsigned char UINT8, *PUINT8; typedef unsigned short UINT16, *PUINT16; typedef unsigned intUINT32, *PUINT32; typedef unsigned __int64UINT64, *PUINT64; ... ( from windows.h ) so it shouldn't be difficult to emulate unix types in compiler.h using these types that are legacy from the old good times of OS/2 ;-) -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] net_fdm.hxx net_ctrls.hxx
Curtis L. Olson wrote: I see that Linux (C99) has an inttypes.h include that defines: int8_t, int16_t, int32_t, int64_t and uint8_t, uint16_t, uint32_t, uint64_t I looked this stuff up recently while doing some work on Nasal. The header you really want is stdint.h, which is where the C99 standard says the definitions for these types are (the glibc inttypes.h includes stdint.h, but I'm not 100% sure if that's part of the standard or not). Unfortunately, MSVC doesn't have this header yet as of the most recent VS.NET release. Here is a Darwin header file that popped up when I googled the issue with a putative workaround: http://www.opensource.apple.com/darwinsource/10.3/mDNSResponder-58/mDNSWindows/DNSServices/DNSServiceDiscovery.h Which, of course, basically does this: #ifdef _MSC_VER typedef signed charint8_t; typedef unsigned char uint8_t; typedef signed short int16_t; typedef unsigned short uint16_t; typedef signed longint32_t; typedef unsigned long uint32_t; #else #include stdint.h #endif The fact that this is an apple header implies that it ought to work out of the box on OS/X and the various BSDs. The only other platforms we support right now are SGI and Solaris, right? Can anyone check the status of stdint.h on those platforms? Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] net_fdm.hxx net_ctrls.hxx
Andy Ross wrote: The fact that this is an apple header implies that it ought to work out of the box on OS/X and the various BSDs. The only other platforms we support right now are SGI and Solaris, right? Can anyone check the status of stdint.h on those platforms? SGI: present and supported. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] net_fdm.hxx net_ctrls.hxx
Erik Hofman wrote: Andy Ross wrote: The fact that this is an apple header implies that it ought to work out of the box on OS/X and the various BSDs. The only other platforms we support right now are SGI and Solaris, right? Can anyone check the status of stdint.h on those platforms? SGI: present and supported. Ok, I'm going to commit some changes to the net_fdm.hxx, net_ctrls.hxx, and net_gui.hxx files. I bumped up the embedded version number. I *think* I took care of all the details, but there's always a chance I missed something. Let me know right away if any one has problems. Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
