Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!mcvax!cernvax!ethz!prl
From: prl@ethz.UUCP (Peter Lamb)
Newsgroups: comp.lang.c
Subject: Re: Byte vs. Word Alignment - (nf)
Message-ID: <65@bernina.UUCP>
Date: Tue, 21-Apr-87 05:01:33 EST
Article-I.D.: bernina.65
Posted: Tue Apr 21 05:01:33 1987
Date-Received: Thu, 23-Apr-87 04:49:52 EST
References: <6700007@iaoobelix.UUCP>
Reply-To: prl@bernina.UUCP (Peter Lamb)
Organization: ETH Zuerich, Switzerland
Lines: 30

In article <6700007@iaoobelix.UUCP> wagner@iaoobelix.UUCP writes:
>
>	struct foo {
>		char frob_1;
>		int frob_2;
>	};
>
>I intended to send something like the above structure as a packet over the
>net. You know what happened? The VAX/uVAX produces *8* as sizeof struct foo,
>whereas the Sun program yields *6*.

I am always surprised when people write code that sends raw binary
data, especially structures, over networks. I can imagine that there
will be lots of horrible hacking to make this all work between Sun and
Vax, then along comes another machine with yet other sizes/alignment
requirements and the whole thing gets worse and worse....  (the size of
the above array on a PDP11, for example, is *4*).

Wait until you want to send *floats* :-( .

The safest way to send data (especially floats) is as an array of bytes
with an agreed most-to-least significant byte ordering. For floating
point break out the exponent and fraction and encode them separately:
make sure that the exponent is always to the same base (IBM 360 &
lookalikes have base 16 not base 2; ie fpnum = fraction * 16^exponent).

If portability rather than efficiency is the main consideration, use a
printable encoding using sprintf/ato[ilf].

Writing code which handles binary data portably is *hard*.