Re: resizing an array, is there a better way?

From: Keith Thompson (kst-u_at_mib.org)
Date: 08/05/04 

Date: Thu, 05 Aug 2004 01:12:58 GMT

Jens.Toerring@physik.fu-berlin.de writes:
> Keith Thompson <kst-u@mib.org> wrote:
[...]
> > All this is, of course, extremely system-specific. Michael is quite
> > correct: you *don't know* what realloc does.
>
> System-specific or not, would you be prepared to tell which implemen-
> tations you were testing that with?

Cygwin under Windows XP and Solaris 8. On Cygwin, the behavior was
unaffected by the extra malloc() call; on Solaris, it caused the
realloc() to move the block more often.

Actually, I should have stated it more strongly. It's not just
system-specific; it can depend strongly on the current state of the
heap (assuming there is such a thing), which can depend on what else
the program has been doing, and quite possibly on the phase of the
moon.

[...]
> > Here's the program. One caveat: the "ptr != prev" comparison probably
> > invokes undefined behavior when realloc() moves the memory block and
> > ptr becomes invalid.
>
> As far as I understand the constraints, comparing pointers for equality
> or inequality is absolutely ok, only trying to establish a relation like
> that one is larger than the other gets you into muddy waters.

If the realloc() call moves the block of memory, the old pointer value
becomes invalid, just like a pointer that's been free()d.. Any
attempt to refer to that value will invoke undefined behavior. In
nearly all real-world implementations, an equality comparison will
just compare the bits, and it will work as expected -- but an
implementation could, for example, load the value into an address
register for the comparison, and this could trigger a validity check. 

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center             <*>  <http://users.sdsc.edu/~kst>
We must do something.  This is something.  Therefore, we must do this.

Relevant Pages

  • Re: Does malloc() reuse addresses?
    ... No no, Im no examining the moemory that hte pointer points to, I am ... simply comparing the values of the pointers themselves, ... dereferencing it, invokes undefined behavior. ... void *ptr; ...
    (comp.lang.c)
  • Re: function called through a non-compatible type
    ... > different sizes and a void pointer must be big enough to contain any ... void* pointers than for int* pointers. ... it invokes undefined behavior on all systems. ...
    (comp.lang.c)
  • Re: is NULL-checking redundant in accessor-functions?
    ... >> The standard says so. ... you refer to the value of p (without dereferencing it). ... If p either points to a valid object or is a null pointer, ... to NULL, though it invokes undefined behavior, will not actually cause ...
    (comp.lang.c)
  • Re: Does malloc() reuse addresses?
    ... No no, Im no examining the moemory that hte pointer points to, I am ... dereferencing it, invokes undefined behavior. ... as long as no attempts are made to dereference it. ...
    (comp.lang.c)