Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!burl!ulysses!bellcore!decvax!ittatc!dcdwest!sdcsvax!sdcrdcf!hplabs!hpda!hpisoa2!hpitg!brl-smoke!rbj@icst-cmr From: rbj@icst-cmr Newsgroups: net.lang.c Subject: Re: Byte order (retitled) Message-ID: <383@brl-smoke> Date: Tue, 29-Apr-86 19:35:00 EDT Article-I.D.: brl-smok.383 Posted: Tue Apr 29 19:35:00 1986 Date-Received: Tue, 13-May-86 00:30:02 EDT References: <7046@cca> Lines: 41 > In article <1117@psivax.UUCP> friesen@psivax.UUCP (Stanley Friesen) writes: > >In article <2590@utcsri.UUCP> greg@utcsri.UUCP (Gregory Smith) writes: > >>... > > And I am saying that the following *should* be portable, and > >that any implementation that it doesn't work on is brain-damaged. > > > > register int i; > > unsigned char bytes[ sizeof( long )]; /* lo-byte first */ > > long input; > > register char *cvptr; > > > > for(cvptr = (char *)&input, i = 0; i < sizeof(long); i++) > > bytes[i] = cvptr[i]; > > > Sorry - I thought you were suggesting that big-endian pointer conversions > should set the lower bits (when pointing to a smaller object) and clear > them (when pointing to a larger one). What you are actually saying is > that any implementation which is not strictly little-endian is 'brain- > damaged' (Including (a) PDP11 _longs_, (b) 68000). I will agree that (a) > is brain-damaged, but I think the adjective is a little strong for (b). > I am a little-end fan myself, but I can face reality, and the reality is > there will be big-endian machines around that are still worth using, and > that the 'problem' can be dealt with so easily that one needn't damn > the 68K to eternal flames on this one point. > > "For every action there is an equal and opposite malfunction" > ---------------------------------------------------------------------- > Greg Smith University of Toronto UUCP: ..utzoo!utcsri!greg To all you Big Endian fans out there: What's your problem? You guys are the ones saying that the first byte is the most significant, so why are y'all bitchin that you don't get the low byte like on *sane* machines? Axually, I like the 680[012]0 also. Byte order doesn't really bother me either way except as an academic issue. I don't see the need or the possibility for your example to be both portable and work the way you described. The two are at odds. Remember, C does what you tell it to do, not what you think it should do. (Root Boy) Jim Cottrell "One man gathers what another man spills"