Re: [VANILLA-LIST:3131] Binary portability

[Jeffrey Nowakowski <jeffno@ccs.neu.edu>]

Dave Ahn <ahn@vec.wfubmc.edu> wrote:
>
> This is a question of endianness not Windows vs Unix.

Yeah I know but I read that most Unixes were one endian and Windows another.

> The netrek packets are translated from host to network byte order
> before transmission.  The recipient takes the bytestream and
> converts it back to its own host byte order before using the values.

Ok, that explains how the network works for endiannes.

> You may be getting an extra byte swap in the cambot file.  Since I haven't
> looked at the server and client cambot code, I couldn't say for sure.

There shouldn't be any swapping done, because the packets that are
written to the cambot file have not gone through the network.

> Binary file portability deals with endianness, data type sizes, alignment,
> padding, etc, etc, etc.  Fortunately for netrek, most of these issues
> are avoided with the exception of endianness.

How are they avoided?  Isn't it up to the compiler on a particular
platform to determine all the stuff you mentioned above?  What about
64 bit machines?

Essentially what I am hearing is that client and server recordings are
not compatible across different endian machines, and we are just lucky
that we don't run into other issues such as alignment.

For example, here is another entry from the C FAQ:

My compiler is leaving holes in structures, which is wasting space and
preventing ``binary'' I/O to external data files. Can I turn off the
padding, or otherwise control the alignment of structure fields?

Your compiler may provide an extension to give you this control
(perhaps a #pragma; see question 11.20), but there is no standard
method.

-Jeff