Path: utzoo!attcan!uunet!aplcen!uakari.primate.wisc.edu!sdd.hp.com!decwrl!pacbell.com!pacbell!osc!jgk
From: jgk@osc.COM (Joe Keane)
Newsgroups: comp.arch
Subject: Re: RISC hard to program?
Message-ID: <3194@osc.COM>
Date: 24 Jul 90 23:43:09 GMT
References: <1878@charon.cwi.nl> <12281@encore.Encore.COM>
Reply-To: jgk@osc.COM (Joe Keane)
Organization: Object Sciences Corp., Menlo Park, CA
Lines: 23

In article <12281@encore.Encore.COM> jkenton@pinocchio.encore.com (Jeff
Kenton) writes:
>The "correct answer" to this seems to be something of a religious question.
>It depends on whether you think network packets are defined as structures
>or as byte streams.  If you call them structures you have both alignment
>problems and big-endian/little-endian problems.  If you call them byte
>streams you have neither problem, but the code looks uglier.

In my opinion, almost all of the whining about alignment comes from people who
write code with `write(fd, some_struct_pointer, sizeof (struct foo))' and
expect it to be portable.  Never mind alignment, think about machines with
different type sizes, different byte order, or different floating-point
formats.  You can do it, but don't cry to me when it stops working.

Network packets are defined as a sequence of bytes.  The second arguments to
read and write are char pointers.  This suggests that you should only read and
write arrays of bytes.  You can convert between these and whatever internal
form you want.

It may seem like a pain to do this, but it pays off.  I wrote programs which
read and write complicated data formats, with weird floating-point numbers and
all.  Then i went to a machine with a different byte order and floating-point
format, and they ran fine, without changing a single line of code.