Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!brl-adm!adm!wesommer@athena.mit.EDU
From: wesommer@athena.mit.EDU
Newsgroups: comp.lang.c
Subject: Re: Byte vs. Word Alignment - (nf)
Message-ID: <7013@brl-adm.ARPA>
Date: Tue, 21-Apr-87 10:57:17 EST
Article-I.D.: brl-adm.7013
Posted: Tue Apr 21 10:57:17 1987
Date-Received: Wed, 22-Apr-87 03:19:51 EST
Sender: news@brl-adm.ARPA
Lines: 36

In article <6700007@iaoobelix.UUCP> wagner@iaoobelix.UUCP writes:
>Byte vs. word alignment is a problem I have encountered recently when I
>tried to setup a simple server/client connection using sockets. The problem
>was that you get very strange results on a VAX/uVAX/Sun if you print out
>sizeof(struct foo) where struct foo is:
        [ a structure with an char and an int ]

You're *still* in trouble even if the two compilers used the same
alignment rules.  Ever hear of byte order?

The "right" way to do something like this is to use an architecture
independant network representation, like SUN's XDR  (eXternal Data
Representation), or Universal Stream Protocol (developed by Clark et.
al. at MIT).  To assume that you can declare a structure and just copy
its bit image onto the net and onto another machine is incorrect.

>Maybe there should be a compiler switch -dont_align forcing the compiler to
>take things literally, i.e. to leave these structs unchanged even if their
>size is an odd number of bytes. The structures themselves could be word
>aligned *in memory*, however, but the internal structure would be as the
>programmer defined it.

That's not going to work on some architectures.  For example, on an
IBM RT PC, you *can't* do an unaligned longword load in any kind of
efficient manner (the hardware *silently* rounds your pointers down).
On other architectures, you get a hardware trap if you try and do
this.  All the world is not a VAX.. or even a 32 bit register machine
with 8 bit byte addressable memory.

                    Bill Sommerfeld
                    MIT Project Athena
                  ARPA: wesommer@athena.mit.edu
                  UUCP: ...!mit-eddie!wesommer

"C is PL/I that's been left on the stove too long (most of it
has boiled away)"