From: "Mark E." <snowball3 AT bigfoot DOT com>
To: djgpp-workers AT delorie DOT com
Date: Sat, 2 Jun 2001 13:35:10 -0400
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Re: realloc patch
Message-ID: <3B18EB8E.26501.AE79B@localhost>
In-reply-to: <2950-Sat02Jun2001192551+0300-eliz@is.elta.co.il>
References: <3B18BAC2 DOT 21715 DOT 587E2 AT localhost> (snowball3 AT bigfoot DOT com)
X-mailer: Pegasus Mail for Win32 (v3.12c)
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

> So you are saying that "after_size - alloc_delta" and alloc_delta
> always have their LSB cleared?  Is that guaranteed for all possible
> values of these variables?

after_sz's LSB will be clear because the function returns if it isn't.

alloc_delta = new_size - old_size

old_size's LSB will be clear because realloc clears it before realloc_inplace 
is called. new_size's LSB will be clear because it's aligned at ALIGN 
boundary (which is 8) and even numbers will never have their LSB set.

So yes I believe the code is safe.