Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site brl-tgr.ARPA
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!genrad!panda!talcott!harvard!seismo!brl-tgr!gwyn
From: gwyn@brl-tgr.ARPA (Doug Gwyn )
Newsgroups: net.lang.c
Subject: Re: C portability gotcha, example
Message-ID: <2731@brl-tgr.ARPA>
Date: Fri, 1-Nov-85 23:03:59 EST
Article-I.D.: brl-tgr.2731
Posted: Fri Nov  1 23:03:59 1985
Date-Received: Sun, 3-Nov-85 16:46:53 EST
References: <2482@brl-tgr.ARPA>
Distribution: net
Organization: Ballistic Research Lab
Lines: 16

> One of the fellows here ran across a C coding style problem
> that caused an application to break when ported from little-
> endian machines to a big-endian.  I am posting this to help
> those who may encounter similar problems in the future.

Rwells@BBN-PROPHET.ARPA has pointed out to me that this is not
necessarily a big-endian problem, and that the example would
work on many big-endian systems and may fail on some little-
endians.  It should really be described as a program that
malfunctioned when ported to a machine with *more stringent
alignment constraints*.  Those of you who were puzzled may
find this to be the clue you needed.

(Big-endianness would have to be combined with data addressing
at the high-address byte before it would be the causal factor;
this combination appears to be rarer than I at first believed.)