X-Authentication-Warning:	delorie.com: mailnull set sender to djgpp-workers-bounces using -f
From:	sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id:	<10202121628.AA14162@clio.rice.edu>
Subject:	Re: Alignment problem
To:	rudd AT cyberoptics DOT com
Date:	Tue, 12 Feb 2002 10:28:57 -0600 (CST)
Cc:	eliz AT is DOT elta DOT co DOT il, djgpp-workers AT delorie DOT com
In-Reply-To:	<3C6933C5.C7C22E16@cyberoptics.com> from "Eric Rudd" at Feb 12, 2002 09:24:53 AM
X-Mailer:	ELM [version 2.5 PL2]
Mime-Version:	1.0
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

> Charles Sandmann wrote:
> 
> > The drawback in this (if I remember the code correctly) is that rv will never be
> > == expected_sbrk, so we always waste an extra boundary tag in addition to the
> > additional 7 bytes lost.
> 
> The 7 bytes are lost only each time the pointer has to be re-aligned, not on every
> malloc call.  I didn't think that 7 bytes was significant.

The idea was a good one - 7 bytes are not that much.  It has a few 
unintended consequences (clear to me since I wrote the mess called sbrk() ).

The base malloc() size is always a factor of 8, so if we unconditionally add
7 bytes to that we force the next sbrk() to be unaligned (unless we were
already at the 1 byte offset point).  Thus 7 out of 8 malloc calls will
be unaligned due to the sbrk() alignment - so 7 bytes on average,
plus the extra 8 bytes due to not merging boundary tags.  This also would
prevent merging blocks to make a larger block since they would
not be adjacent 7/8 of the time.

The extra 8 bytes are only used in a realloc() or free + new malloc() - 
but today they allow users to buffer overflow 8 bytes usually
without being caught.  If the new sbrk() block is not adjacent then
you don't get the extra 8 bytes - which is a hidden consequence which
would make malloc less tolerant of buggy apps.  Maybe this would be a
good thing ;-)

Eric, thanks for pushing this.  Finding the problem, writing test code to
fix it, plus the discussion on best ways to fix it are what improve the
library.  I'll try to do a quick example of the other way I considered
so the list can review it also.

- Raw text -