Date: Mon, 10 Jun 1996 17:50:48 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To: Shawn Hargreaves <slh100 AT unix DOT york DOT ac DOT uk>
Cc: Charles Sandmann <sandmann AT clio DOT rice DOT edu>, djgpp AT delorie DOT com
Subject: Re: Allegro Compatibility
In-Reply-To: <Pine.SGI.3.91.960610145105.26527A-100000@tower.york.ac.uk>
Message-Id: <Pine.SUN.3.91.960610174529.3539C-100000@is>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII



On Mon, 10 Jun 1996, Shawn Hargreaves wrote:

> How does libc handle it?

You mean to say that you do serious work with DJGPP without libc sources 
installed ;-) ?

> It must define it somewhere (at least I assume 
> so, because there is no linker error if a program doesn't provide it) but 
> it can be overridden at will. I have a feeling that might be because libc 
> defines it to be zero, but in that case my definition in Allegro ought to 
> work the same because I'm currently just zeroing it to force the non-move 
> sbrk() algorithm...

If you are willing to trust the library to never change the default 
setting, you don't need to set the bit yourself.  But if you want to be 
*sure* that the non-moving sbrk will be used, there is no other way than 
to set the bit to whatever you need.

This particular bit (unlike some other bits) is tested by `sbrk' every
time it allocates another chunk of memory (look in src/libc/crt0/crt0.s in
the library sources), which explains why you can change the behavior at
runtime.