Newsgroups: comp.protocols.tcp-ip
Path: utzoo!henry
From: henry@zoo.toronto.edu (Henry Spencer)
Subject: Re: Byte and bit order within packet headers
Message-ID: <1991Apr26.193159.9017@zoo.toronto.edu>
Date: Fri, 26 Apr 1991 19:31:59 GMT
References: <9104241753.AA21589@dino.alias.com>
Organization: U of Toronto Zoology

In article <9104241753.AA21589@dino.alias.com> mandrews@alias.com (Mark Andrews) writes:
>... what about the
>bit order? It is still little-endian (bits are numbered right to left instead
>of left to right)! What order is are the bits transmitted in?

Fortunately, this is not an issue, because the data is fed to the hardware
as bytes (usually) and consequently it is the hardware's business to get
the bit order right on both ends.  The usual practice is to send lsb first,
but this is completely invisible to the software.

There is sometimes confusion about how the bits are *numbered*, but that
is a separate issue.  The high-order bit is always the high-order bit and
is always in the same place, regardless of whether the manual calls it
bit 7 or bit 0.

>This is further complicated by the following code fragment from
>/usr/include/netinet/ip.h:

Here we have a different issue.  The reason why ip.h is #if'd is that C
does not define the order of bitfields within a word, and it is both
machine-specific and compiler-specific.  Using bitfields for this was
dumb, actually; convincing them to match an externally-defined storage
layout can be tricky.

>Now according to the 4.3BSD C Reference Manual by B. Kernighan, the addresses
>of a structure increase as the declarations are read left to right...

Bitfields do not have addresses and that rule does not apply to them.
-- 
And the bean-counter replied,           | Henry Spencer @ U of Toronto Zoology
"beans are more important".             |  henry@zoo.toronto.edu  utzoo!henry