Byte order (retitled)

[John Rose]

In article <1117 at psivax.UUCP> friesen at psivax.UUCP (Stanley Friesen) writes:
>In article <2590 at utcsri.UUCP> greg at utcsri.UUCP (Gregory Smith) writes:
>>
>>I strongly disagree. If you have long *x, then (char)*x ( as opposed to
>>*(char*)x ) is the low-order byte of the pointed-to long and is
>>portable.
>
>	What I was trying to say is that *both* should be portable and
>equivalent.
>.....
>	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];
>
>				Sarima (Stanley Friesen)

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.

But the funny thing is, a C compiler *could* be designed to make Sarima's
code work on a big-endian machine.  Pointer ordering and arithmetic could
be defined, in a self-consistent way, *backwards* from the machine-word
ordering.  Arrays and structs would be allocated backward in memory.
(As a bonus, conversion between pointers and ints could involve a negation,
but portable C makes no such requirements.)  In essence, the abstract
addressing structure imposed by this hypothetical compiler would turn
our misguided big-endian machine into a virtual little-endian.

This hack fails for the waverers, such as PDP-11's.  (However, you
could complement the 1s bit before and after index arithmetic?)
Be wrong, but be consistent!

Disclaimers:  This was not a serious suggestion to the compiler designers
of the world.  It certainly has nothing to do with the official policy
of Thinking Machines Corporation.  :-) :-) :-)

[P.S. Sarima, if this was your meaning all along, sorry to steal your
      thunder; I must have missed an article.]

[P.P.S. Local work crunch precludes retro-flame on &array responses.
	But stay tuned, netters.]
-- 
----------------------------------------------------------
John R. Rose		     Thinking Machines Corporation
245 First St., Cambridge, MA  02142    (617) 876-1111 X270
rose at think.arpa				  ihnp4!think!rose