🚀 go-pugleaf

In article <4apn8t$bs8@newshost.lanl.gov> tanmoy@qcd.lanl.gov (Tanmoy Bhattacharya) writes:
>In article <4apkl2$8sp@rdsunx.crd.ge.com>, volpe@bart.crd.ge.com (Christopher
>R. Volpe) writes: 
>|> In article <818898225snz@genesis.demon.co.uk>, Lawrence Kirby
><fred@genesis.demon.co.uk> writes: 
><snip>
>|> |>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.
>
>But even if the byte values change, does it mean that realloc has moved the
>stuff? There may be holes which change: or two different byte values may
>correspond to the same pointer for other reasons.
>
>Of course, if the byte values are identical, any reasonable interpretation of
>the standard will say that the pointer is unchanged.

One could imagine a CPU which had a virtual memory system tighly
coupled to am allocator in which malloc() simply returned an index to
some internal table within the CPU which mapped the memory. In this
case, the object may have been copied, altered in size or packing or
whatever, and given the same table entry. The pointer, viewed as a
string of bytes would remain unchanged, the object pointed to might
well have been moved and altered internally.



-- 
Jim Segrave        (Segrave Software Services jes@grendel.demon.co.uk)
                                             or    jes@demon.net