Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!cbosgd!gatech!seismo!umcp-cs!chris
From: chris@umcp-cs.UUCP (Chris Torek)
Newsgroups: net.unix,net.unix-wizards
Subject: Re: using malloc and brk: something to watch out for
Message-ID: <2112@umcp-cs.UUCP>
Date: Sat, 21-Jun-86 04:56:54 EDT
Article-I.D.: umcp-cs.2112
Posted: Sat Jun 21 04:56:54 1986
Date-Received: Sun, 22-Jun-86 07:18:50 EDT
References: <49@houligan.UUCP>
Reply-To: chris@maryland.UUCP (Chris Torek)
Organization: University of Maryland, Dept. of Computer Sci.
Lines: 23
Xref: watmath net.unix:8319 net.unix-wizards:18541

In article <49@houligan.UUCP> dave@smaug.UUCP (Dave Cornutt) writes:
>... at least on our system (UTX/32, a 4.2BSD derivative), malloc
>maintains its own notion of where the top of memory is, and it doesn't
>know about brk or sbrk calls done external to it.  (Actually, this makes
>sense from a performance standpoint: if malloc had to check the actual
>top of memory, that would mean a system call for every malloc.)

Not so; and someone may have changed the allocator for UTX, for I
believe that the standard 4.2 malloc did not mind programs increasing
the break.  It does not require one system call per malloc, only
one extra system call per `morecore' (an internal routine used to
get more space by calling sbrk).

Note, however, that decreasing the break will confuse most mallocs,
including the standard 4.2BSD version.

The `moral' in the quoted article does, with some changes, apply to
any code that is to be called `portable': mix not malloc() and brk(),
lest ye someday sorrow.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 1516)
UUCP:	seismo!umcp-cs!chris
CSNet:	chris@umcp-cs		ARPA:	chris@mimsy.umd.edu