Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!uwm.edu!ux1.cso.uiuc.edu!m.cs.uiuc.edu!zweig
From: zweig@cs.uiuc.edu (Johnny Zweig)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Byte and bit order within packet headers
Message-ID: <1991Apr26.200406.29162@m.cs.uiuc.edu>
Date: 26 Apr 91 20:04:06 GMT
References: <9104241753.AA21589@dino.alias.com>
Sender: news@m.cs.uiuc.edu (News Database (admin-Mike Schwager))
Reply-To: zweig@cs.uiuc.edu
Organization: University of Illinois, Dept. of Comp. Sci., Urbana, IL
Lines: 26
Nntp-Posting-Host: cassius.cs.uiuc.edu

My solution is never to use bit-fields when decoding packets. Just mask things
with 0x0F and 0xF0 and let the compiler optimize it.

The problem is not a network thing but a C language thing. Quoting from K&R
(2nd ed.):

	Almost everything about [bit] fields is implementation-dependent.
	... Fields are assign left to right on some machines and right to
	left on others.

The term machine here is misleading -- it is actually the implementation of C
on a particular machine that decides what to do with bit fields. One could
imagine two different compilers on the same architecture that did it
differently.

So just get a compiler with inline expansion and a decent optimizer and define
functions to access fields inside of headers.

And this htonl() ntohs() is a poor solution to the problem. It is too easy to
forget what byte-order a particular int currently is in. In my TCP/IP
implementation (in C++) I have a class that hides all that junk. I just assign
values into number-holders according to what byte order they are in, and
retrieve the values in the appropriate order for manipulation.  This makes
errors such as calling htons() twice never happen....

-ynnhoJ redro-etyB