Date: Sat, 02 Jun 2001 14:00:51 +0300
From: "Eli Zaretskii" <eliz AT is DOT elta DOT co DOT il>
Sender: halo1 AT zahav DOT net DOT il
To: "Mark E." <snowball3 AT bigfoot DOT com>
Message-Id: <7458-Sat02Jun2001140050+0300-eliz@is.elta.co.il>
X-Mailer: Emacs 20.6 (via feedmail 8.3.emacs20_6 I) and Blat ver 1.8.9
CC: djgpp-workers AT delorie DOT com
In-reply-to: <3B11464B.28287.D7FE4@localhost> (snowball3@bigfoot.com)
Subject: Re: realloc patch
References:  <3B11464B DOT 28287 DOT D7FE4 AT localhost>
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

> From: "Mark E." <snowball3 AT bigfoot DOT com>
> Date: Sun, 27 May 2001 18:24:11 -0400
> 
> This patch should be done barring any problems discovered during this review.

On closer look, I see here something that worries me.  `malloc' sets
the last bit of the size and endsz fields in the block it allocates:

  #define RET(rv) CHECK(rv); ENDSZ(rv) |= 1; rv->size |= 1; return DATA(rv)

(The macro RET is used throughout in `malloc', whenever it returns a
block to the caller.)

This bit is used in `free':

  if (! (AFTER(block)->size & 1))
  {
    CHECK(AFTER(block));
  }
  if (! (BEFSZ(block) & 1))
  {
    CHECK(BEFORE(block));
    block = merge(BEFORE(block), block, BEFORE(block));
  }
  CHECK(block);
  if (! (AFTER(block)->size & 1))
  {
    CHECK(AFTER(block));
    block = merge(block, AFTER(block), AFTER(block));
  }

However, `realloc_inplace' doesn't use the RET macro (it can't), and
doesn't set that LSB either.  It simply returns the block it found
with the size and endsz fields intact.

Won't that give us trouble when `free' comes to free the blocks found
by `realloc_inplace'?