rose@think.ARPA (John Rose) (04/25/86)
In article <1117@psivax.UUCP> friesen@psivax.UUCP (Stanley Friesen) writes: >In article <2590@utcsri.UUCP> greg@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@think.arpa ihnp4!think!rose
jsdy@hadron.UUCP (Joseph S. D. Yao) (05/08/86)
In article <5056@think.ARPA> rose@think.UUCP (John Rose) writes: >In article <1117@psivax.UUCP> friesen@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@seismo.{CSS.GOV,ARPA,UUCP}