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:	<10202112312.AA22795@clio.rice.edu>
Subject:	Re: Alignment problem
To:	rudd AT cyberoptics DOT com
Date:	Mon, 11 Feb 2002 17:12:15 -0600 (CST)
Cc:	eliz AT is DOT elta DOT co DOT il, djgpp-workers AT delorie DOT com
In-Reply-To:	<3C684B4A.3AC31AA2@cyberoptics.com> from "Eric Rudd" at Feb 11, 2002 04:52:58 PM
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

> Here is a patch that seemed to work (though I've only given it a cursory
> test).  Please take a look at it and see whether I have made a mistake:

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.

> !   rv = (BLOCK *)sbrk(chunk_size+ALIGN1);
...
> +   rv = (BLOCK *) (((int)rv + ALIGN1) & ~ALIGN1);  /* Align the pointer. */

>     if (rv == expected_sbrk)
>     {
>       expected_sbrk = (BLOCK *)((char *)rv + chunk_size);

If we were going to do this I would prefer to send the extra few bytes on
the end that we allocate back to sbrk() via a negative sbrk() or brk() call.
This would allow expected_sbrk to work and not waste the memory in the
rest of the time we don't need them.

> It seemed to me that simply keeping sbrk() at least 7 bytes ahead of the
> expected end of the region was simpler and safer.  I don't know whether there
> are people doing multi-threaded stuff out there, but if they are, I fear that
> sbrk() could get called with some bad (size % 8 != 0) value between the two
> times it is called in the above scheme.  Or is malloc() inherently
> non-re-entrant?

I know that sbrk() isn't reentrant, and malloc has several static variables
also so probably isn't reentrant either.

> Aha!  However, I think that forcing malloc() to work with non-aligned sbrk()
> values is a better solution than requiring alignment from stubinfo, since it
> makes the code less intertwined.

I agree - and it also fixes the problem if someone calls sbrk() with a 
weird value.

- Raw text -