source: etc/campbell/dev-notes/2012-10-10-pointer-off-the-end.txt

Another, more serious, consequence of allowing a pointer just after an object:
When we coalesce memory blocks to form stack frames the pointer comparison
must be careful.  At the moment, we break in this kind of situation:

  ┌───────┐    ┌───────┐
  │ int x │    │ int y │
  └───────┘    └───────┘
          ↑    ↑
     &x + 1 != &y

these pointers are different in Clight.  But in Cminor:

  ┌───────┬───────┐
  │ int x │ int y │
  └───────┴───────┘
          ↑
    &x + 1 == &y

So we break pointer comparison.  We can't possibly preserve pointer comparison
without putting restrictions on the ordering of stack frames, or adding extra
padding, so the best solution is to consider the original comparison to have
undefined behaviour because it is comparing a pointer-off-the-end with a pointer
from another block.

It gets a little worse: we're currently missing range checks in common/
FrontEndOps.ma.  Or is it?  We've already formed stack frames for the variables,
although we could get into trouble with global variables.

[6th Nov:]

And another problem that Ilias noticed: when a block is free it is made invalid
by changing the bounds to make it impossible to have a valid pointer; but the
definition I wrote for the off-the-end pointers in response to the above only
checks the pointer w.r.t the upper bound, so fails to spot an invalid block.
We're just going to drop these now - the back end doesn't have any specific
support for them (and is broken for inter-block comparisons at the moment, too).