Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!samsung!munnari.oz.au!cs.mu.OZ.AU!kre
From: kre@cs.mu.oz.au (Robert Elz)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Byte and bit order within packet headers
Message-ID: <kre.672861301@mundamutti.cs.mu.OZ.AU>
Date: 28 Apr 91 17:55:01 GMT
References: <9104261535.AA28580@alias.alias.com>
Sender: news@cs.mu.oz.au
Lines: 54

mark@alias.com (Mark Andrews) writes:

>Unfortunately, the bit order is machine and compiler dependent.

This is true, in a sense.

Bu this ...

>On little endian machines, the bit fields are assigned least significant bit
>first (right to left),

>On big endian machines, the bit fields are also assigned least significant
>bit first, but this time the bit fields are assigned left to right:

Is simply wrong, or perhaps inaccurate.  Except on those processors
that have "extract/insert bitfield" instructions, the order in which
bitfields are placed in a byte (or whatever) is purely compiler
dependant - on a little endian host you could assign bit fields either
way, on a big endian host you could assign bit fields either way.

Even with a host with bitfield instructions, the compiler could do
it either way (the bit numbers of the fields will be constant,
whether the compiler omits instructions to extract bits 0-3 or
4-7 when fetching the ip_v field is pretty much irrelevant to
anything - except the expectations of the author of the code).

The ifdef's in the BSD source are just a latent bug waiting to bite
someone who isn't very careful porting the code to a new compiler.
(It just happens to work out right on the compilers the code is
normally compiled with).

>In which order are the bits transmitted such that the integrity of the
>data is not compromised, independent of the endian order.

It depends entirely on the medium over which the data is being sent,
and only on that - on serial (point to point) wires, sync or async,
and on ethernet (ISO 8802/3) the least significant bit is sent
first, on rings the most significant bit is sent first, if you
happen to have an 8 bit parallel bus, then all the bits are sent
simultaneously..., but as long as all the hardware understands this
the most significant bit of a received byte will be the most
significant bit of the transmitted byte, so once the hardware is
designed & built correctly you never need to worry about this.

On the other hand, you do need to worry about the order of the bytes
wrt their interpretation as multi-byte objects (int's etc), and
thw way that the compiler lays out storage in structs, including bits
for bit fields.  Anyone attempting to use struct definitions to
represent network packet formats must have intimate knowledge of the
way the compiler works - and should the compiler decide to change
from one version to another, and the network code breaks because
of that, its a bug in the net code - not the compiler.

kre