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
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
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
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
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
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
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
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,
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
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
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
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
12 matches
Mail list logo
