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.)