Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!caen!uwm.edu!linac!att!ucbvax!ulysses!kpv
From: kpv@ulysses.att.com (Phong Vo[drew])
Newsgroups: comp.unix.questions
Subject: Re: sbrk(2) question
Message-ID: <14497@ulysses.att.com>
Date: 21 Mar 91 01:03:44 GMT
References: <1991Mar8.180132.12025@Think.COM> <4296@skye.ed.ac.uk> <2048@necisa.ho.necisa.oz.au>
Organization: AT&T Bell Laboratories, Murray Hill
Lines: 16

In article <2048@necisa.ho.necisa.oz.au>, boyd@necisa.ho.necisa.oz.au (Boyd Roberts) writes:
> In article <4319@skye.ed.ac.uk> richard@aiai.UUCP (Richard Tobin) writes:
> >
> Well there may be no reason, but in reality most malloc(3) implementations
> assume that it and no one else has called sbrk(2).  I'm sure that pre-System V
> implementations were known to break if you mixed sbrk(2) and malloc(3).
> 
Reality points the other way. Most malloc implementations that I've seen
do try to handle sbrk when this is used to obtain space. Whether they do
it right is another issue. In any case, sbrk should never be used directly
by an application to reduce space. This is because free blocks are usually
kept in data structures that involved links of some type and unpredictable
consequences can arise when the space pointed to by these links suddenly
disappear. I do know of one malloc implementation from a friend
that uses no links. Its free strategy is rather wasteful but it's
a great malloc for programs that manipulate space in a stack-like manner.