Message-Id: <199711072108.IAA01247@mona.lexicon.net.au> Comments: Authenticated sender is From: "John Machin" To: djgpp AT delorie DOT com, Christopher Croughton Date: Sat, 8 Nov 1997 08:06:31 +1000 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: re: Memory allocation In-reply-to: <199711070505.AAA11770@delorie.com> Precedence: bulk > From: Christopher Croughton > 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