Ultrix CC bug?

Richard O'Keefe ok at cs.mu.oz.au
Sat Sep 16 18:57:54 AEST 1989


In article <DUPUY.89Sep16000855 at cs.cs.columbia.edu>, dupuy at cs.columbia.edu (Alexander Dupuy) writes:
> 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.

False.  Pointers to char, short, and int on the VAX point to the LEAST
SIGNIFICANT BYTE (as the manual says, the byte containing bit 0, i.e.
the bit which represents 2**0).  If I have
	union { char c; short s; long l;} pun;
in a VAX C program, the memory layout is
	[pun+3] [pun+2] [pun+1] [pun+0] this is not C pointer addition!
	filler	filler	filler  c(all)
	filler  filler  s(msb)  s(lsb)
        l(msb)  l(b 2)  l(b 1)  l(lsb)
	<----------------------------- addresses increase right to left
so &pun, &pun.c, &pun.s, and &pun.l would all have the same address.
The beautiful thing about this is that the least significant bytes are
lined up, so that if I do pun.l = 0; pun.c = 27 then pun.l will be 27,
not some strange scrambling (C in general says _nothing_ about what will
happen in this case).



More information about the Comp.bugs.4bsd.ucb-fixes mailing list