using malloc and brk: something to watch out for

[Chris Torek]

In article <49 at houligan.UUCP> dave at 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 at umcp-cs		ARPA:	chris at mimsy.umd.edu