On Thu, 14 Feb 2002 10:22:24 EST, Mark Mielke said: > Just like, one should be able to assume that "p++" and "--p" should > always work, although very strictly one cannot. The following code: > > char s[100]; > char *p = &s[-2]; > > p[2]; > > May not actually work on some systems. Why? Because C only guarantees that > s[-1] will work. > > I've never stumbled on one of these machines, but I suspect these > limitations may apply to systems without a real OS underneath them, > such as the Palm Pilot. Actually, it's not necessarily "without a real OS". There have existed weird architectures that have strange views on memory access (see the Intel 432, or IBM's S/38-AS/400 series, for example), where memory is referenced in an object-oriented manner enforced by the hardware. On these types of machines, dereferencing p[2] is safe *only* if p is referenced through a pointer that accesses a descriptor that says "yes, this is an array of at least 3 in size". And of course, trying to assign p a value of &s[-2] gets you a SIGSEGV or moral equivalent, because s is a pointer to a descriptor that limits the array to indices 0 through 99. And I believe everybody's favorite CISC system, the DEC VAX, had a BOUNDS instruction that checked if a pointer was within limits - and there's no reason why a compiler couldn't/shouldn't have included a BOUNDS opcode in the computation of &s[-2]. I believe the Intel x86 series has a similar opcode, but I am *NOT* positive of that.... -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech
Attachment:
pgpHGm8jTWUh4.pgp
Description: PGP signature