Byte order (retitled)

[Joseph S. D. Yao]

In article <5056 at think.ARPA> rose at think.UUCP (John Rose) writes:
>In article <1117 at psivax.UUCP> friesen at psivax.UUCP (Stanley Friesen) 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];
>Well, this is certainly false for all existing C's on big-endian machines.
>Even if you make the pointer "(char *)&input" point to the last byte of
>the datum, when you index on it, say by referencing "cvptr[1]", you get
>bytes *past* the last byte of the long datum.

I don't see rose's point.  Attend:
	0:	0123		3210
		big-endian	little-endian
In both cases, if &input == 0, and (cvptr = (char *) &input) == 0,
then cvptr[0-3] will map in the same order to bytes[0-3]; and the
copy succeeds.  Perhaps he is thinking that (char *) &input == 3,
and (short int *) &input == 2?  This is exactly the behaviour that
big-endians do  n o t  do, and which little-endian PDP-11 and VAX-11
programmers despair of because thay can't perform type punning.

Incidentally, don't call an 11 a PDP, because there are radically
different architectures on the PDP-1,-4,-5,-6,-7,-8,-9,-10,-12,-15,
-16,-20,...	;-)
-- 

	Joe Yao		hadron!jsdy at seismo.{CSS.GOV,ARPA,UUCP}