🚀 go-pugleaf

In article <199@infovax.UUCP> bl@infovax.UUCP (Bj|rn Larsson) writes:
> 	*((long *) p)++		has the value of the *long* pointed
> 				to by p, and the *long* pointer is
> 				set to point to the next long (i.e.
> 				if sizeof (long)== 2*sizeof(short)
> 				then p will be incremented by two,
> 				counted in short's).
> 
>   Any objections? I could add that both Turbo C, MicroSoft C, and the
> MicroTek C 68000 cross-compiler compile this as I believe 'correctly'.

Not to contradict Maarten Litmath's analysis, which is entirely correct, but
there's a reason that those compilers accept this construct, and the Ultrix
and most other Vax compilers reject it - endianism.

On a big-endian machine like the 68000, the high order byte comes first, and
pointers to ints, shorts and chars all point to the high order byte, which is
the first byte of the int short or char.  All very convenient, and allows easy
and graceful punning from pointer type to pointer type, even if you bend the
rules of C.

On a little-endian machine like the VAX, the high order byte comes last, and
pointers to ints, shorts and chars all point to the high order byte, which,
since it is the last byte, varies depending on the size of the object.  Quoting
from the VAX architecture handbook, p. 33, "A word, two contiguous bytes,
starts on an arbitrary byte boundary... The bits are numbered from the right 0
through 15.  Words, longwords, quadwords and octawords are specified by their
address A, the address of the byte containing bit 0" (i.e. the last one).

So when you cast a (short *) to a (long *), you are in fact getting a pointer
to bytes which come before the (short *), rather than after, as you might
expect.  This causes the sort of type punning which works so nicely on
big-endian machines to fail miserably.  In order to save programmers from
having to track down such strange bugs, VAX compilers tend to be much stricter
about these sorts of things.

@alex
--
-- 
inet: dupuy@cs.columbia.edu
uucp: ...!rutgers!cs.columbia.edu!dupuy