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
msg07963/pgp00000.pgp
Description: PGP signature
