Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!lll-lcc!styx!ames!ucbcad!ucbvax!CITHEX.CALTECH.EDU!carl
From: carl@CITHEX.CALTECH.EDU (Carl J Lydick)
Newsgroups: mod.computers.vax
Subject: Re: malloc, alloc, etc., and brk and sbrk
Message-ID: <861219182858.003@CitHex.Caltech.Edu>
Date: Fri, 19-Dec-86 21:29:03 EST
Article-I.D.: CitHex.861219182858.003
Posted: Fri Dec 19 21:29:03 1986
Date-Received: Sat, 20-Dec-86 22:43:07 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 13
Approved: info-vax@sri-kl.arpa

This sounds like it may be related to the fact that on UNIX systems, successive
calls to brk or sbrk allocate contiguous chunks of memory, while on VMS
any of a number of things (e.g., a call to RMS) can allocate a chunk of
memory between the two allocated to the calls to [s]brk.  The result is
that if you are lucky enough (in the short run; in the long run, it's a
definite stroke of bad luck) to make the calls to things that allocate memory
in the right order, you might be able to port something from UNIX to VMS
even without being careful about allocating memory.  Of course, next time
you change the program, you may find that the whole thing has to be rewritten
to avoid the problem.  If you've got source, you may want to check for
instances in which multiple calls to [s]brk assume they get contiguous memory.
It worked to device-independent troff and at least one other piece of software
ported from UNIX; it may work for EMACS.