Message-Id:	<199711072108.IAA01247@mona.lexicon.net.au>
Comments:	Authenticated sender is <sjmachin AT mail DOT lexicon DOT net DOT au>
From:	"John Machin" <sjmachin AT lexicon DOT net DOT au>
To:	djgpp AT delorie DOT com, Christopher Croughton <crough45 AT amc DOT de>
Date:	Sat, 8 Nov 1997 08:06:31 +1000
MIME-Version:	1.0
Subject:	re: Memory allocation
In-reply-to:	<199711070505.AAA11770@delorie.com>

> From: Christopher Croughton <crough45 AT amc DOT de>
> Message-Id: <97Nov6.200722gmt+0100 DOT 11649 AT internet01 DOT amc DOT de>
> Subject: Memory allocation
> To: djgpp AT delorie DOT com
> Date: Thu, 6 Nov 1997 19:12:59 +0100
 
> How standard is the sbrk(2) function?  It's on every Unix I've seen,
> and appears to be in DJGPP as well, but it's not as far as I can tell 
> ANSI.  How much can I rely on it being there, and is using it likely
> to mess up malloc etc.?  Does it actually work under DJGPP as it does
> in Unix?

An implementation of sbrk has been provided with all non-Unix C 
compilers that I have used (that I can remember -- BDS C[*1] on a 
Z80[*2], maybe not ...).

Using sbrk and malloc may cause a mess if the malloc naively believes 
that there would never be other calls to sbrk than by malloc itself, 
and thus does something silly like assume it has a contiguous 
play-pen. The malloc in DJGPP libc v 2.01 is not that kind of silly.

DJGPP vs Unix: there are possible subtle differences; you can set crt 
flags to twiddle this --- see following excerpt from v2.01 
crt1.txh doco file:

_CRT0_FLAG_NONMOVE_SBRK

If set, the sbrk() algorithm used used multiple DPMI memory blocks
which makes sure the base of CS/DS/SS does not change.  This may cause
problems with sbrk(0) values and programs with other assumptions about
sbrk behavior. This flag is useful with near pointers, since a
constant pointer to DOS/Video memory can be computed without needing
to reload it after any routine which might call sbrk().

_CRT0_FLAG_UNIX_SBRK

If set, the sbrk() algorithm used resizes memory blocks so that the
layout of memory is set up to be the most compatible with unix sbrk()
expectations. This mode should not be used with hardware interrupts,
near pointers, and may cause problems with QDPMI virtual memory.  If
your program requires a specific sbrk() behavior, you should set one
of these flags, since the default may change in different libc
releases.

> 
> How about the mmap(2) function?  That sounds really useful if it works...
> 

mmap() is not available with DJGPP as at v2.01. It is not available 
with all Unixes.

<< begin sermon >>

Why bother with sbrk? It would be useful only for largish requests 
for chunks of memory that will not be freed until process 
termination. If you are interested in portability, use malloc. If you 
find that for large requests it wastes space, then get another malloc 
or consider using sbrk. Unless your original malloc was written 
by some K00L D00D like b1ff AT aol DOT com and has a factor-of-two bug 
[*3], this should not be necessary.

<< end sermon >>

<< footnotes >>

*1 --- BDS C : a compiler that did not grok "void".

*2 --- Z80 : a CPU design that was limited to 64Kb address space but 
could actually be programmed to do more useful work than some people 
can achieve with 64Mb of real memory.

*3 --- Resemblance to any software or person, living or 
brain-dead, is of course co-incidental.

Hope this helps.

John Machin
1/27 Auburn Grove
Hawthorn East, VIC 3123, Australia
Phone: +61-3-98130561

- Raw text -