www.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-workers/2001/06/02/13:35:08

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
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

> 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.


- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019