🚀 go-pugleaf

In article <4apkl2$8sp@rdsunx.crd.ge.com>,
Christopher R. Volpe <volpe@ausable.crd.ge.com> wrote:
|In article <818898225snz@genesis.demon.co.uk>, Lawrence Kirby <fred@genesis.demon.co.uk> writes:
||>
||>realloc can be thought of as destroying an object (without modifying it)
||>and then creating another one initialised to (an appropriate amount of)
||>the data that was in the first one. This makes sense because no pointer to
||>the original object is valid so long as the call to realloc succeeds. I
||>don't see a problem with shrinking the allocation when the initial and final
||>objects are viewed as distinct. Even if the realloc call returns the same
||>address as the one passed to it no strictly conforming program can rely on
||>this fact or even detect it since all pointers to the original object are
|               ^^^^^^^^^^^^^^
|
|You can detect it. Before calling realloc, look at the pointer value as an
     ^^^^^^^^^^^^^

Well, you might detect it.


|                   Before calling realloc, look at the pointer value as an
|array of (sizeof(void *)) bytes, and save those bytes somewhere. Then compare
|bytes after the realloc. You're not evaluating the pointer, just inspecting
|byte values.

Consider the Intel segmented addressing.  Many 32-bit pointers can
point to the same 20-bit address.  They will not match when compared
as bytes.  realloc() could return any of those.

Cheers,
Stan.
-- 
HELP!  I'M BEING HELD PRISONER IN A .SIGNATURE FACTORY!
    Stan Ryckman   sgr@alden.com