🚀 go-pugleaf

In article <4am3dn$6s9@natasha.rmii.com> jcoffin@rmii.com "Jerry Coffin" writes:

>>It follows from this that realloc could be declared as:
>
>>void *realloc(const void *ptr, size_t size);
>
>>since on failure realloc doesn't change the object pointed to by ptr and
>>on success it returns a pointer to a different object (at least
>>conceptually) to that pointed to by ptr.
>
>Here I have a bit more of a problem -- if realloc can reallocate the
>object in-place, I have a harder time calling it const.  In particular,
>realloc can be used to shrink an allocation as well as expand it.  In
>this case, part of what was previously accessible will no longer be, so
>use of the pointed to object is altered.  IMO, that's not really const
>anymore.

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
indeterminate after the successful call to realloc. So there is no way
for a strictly conforming program to determine that the initial and final
objects are not distinct. Consider the following:

void foo(void);

int main(void)

{
    foo();
    foo();
    return 0;
}

void foo(void)

{
    const int i;
}

In the 2 invocations of foo a const object i is created and destroyed. Even if
the 2 instances of i have the same memory address they must be regarded
as distinct objects because they can never be referenced at the same time,
pointers to them can never be compared, and perhaps most fundamentally their
lifetimes don't overlap. The same is true for the objects that exist
before and after a successful call to realloc. You could conceptualise
realloc as follows:

1. The data in the original object is copied to a temporary array

2. The original object is destroyed

3. A new object is created to the specified size

4. A suitable amount of data is copied from the temporary array to the new
   object

5. A pointer to the new object is returned.

There is nothing in the overall semantics of realloc that suggests that the
lifetimes of the initial and final objects overlap. The description of
memmove uses a similar trick of a conceptual temporary array to define
its semantics.

The description in the standard of realloc talks about changing the size
of an object and possibly moving it. IMHO this is a bad description
since these are two things that can't be done to an object without making it
a different object (either of them will make a nonsense of dereferening
a pointer to that object). I believe the standard should embrace the
concept of the initial and final allocations being 2 distinct objects since
it would make the description consistent with other descriptions and uses
of 'object' in the standard without changing the semantics of realloc.
For instance it would make instantly clear why pointers to the initial
object become indeterminate since that object doesn't exist any more. And
the standard would nowhere suggest the dubious concept of objects
moving or changing size.

-- 
-----------------------------------------
Lawrence Kirby | fred@genesis.demon.co.uk
Wilts, England | 70734.126@compuserve.com
-----------------------------------------