🚀 go-pugleaf

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
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.

--

Chris Volpe				Phone: (518) 387-7766 (Dial Comm 8*833
GE Corporate R&D			Fax:   (518) 387-6560
PO Box 8, Schenectady, NY 12301		Email: volpecr@crd.ge.com