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.