Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxn!ihnp4!qantel!lll-lcc!lll-crg!seismo!brl-adm!brl-smoke!smoke!rbj@icst-cmr From: rbj@icst-cmr (root) Newsgroups: net.lang.c Subject: Re: Byte order (retitled) Message-ID: <383@brl-smoke.ARPA> Date: Tue, 29-Apr-86 10:35:05 EDT Article-I.D.: brl-smok.383 Posted: Tue Apr 29 10:35:05 1986 Date-Received: Fri, 2-May-86 23:15:01 EDT Sender: news@brl-smoke.ARPA 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"