Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!caip!nike!ucbcad!ucbvax!CITHEX.CALTECH.EDU!carl
From: carl@CITHEX.CALTECH.EDU (Carl J Lydick)
Newsgroups: mod.computers.vax
Subject: (none)
Message-ID: <860907032600.006@CitHex.Caltech.Edu>
Date: Sun, 7-Sep-86 06:26:05 EDT
Article-I.D.: CitHex.860907032600.006
Posted: Sun Sep  7 06:26:05 1986
Date-Received: Sun, 7-Sep-86 20:12:30 EDT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 12
Approved: info-vax@sri-kl.arpa

Most programs using sbrk written on a machine running UNIX that I've seen have
the same problem when you try to port them to VMS.  The reason is that they tend
to assume that successive calls to sbrk will return adjacent chunks of (virtual)
memory.  This is true under UNIX.  Under VMS, however, you've got RMS running
around loose, and it dynamically allocates and deallocates memory.  If you want
to get rid of the ACCVIO's track down the code that's assuming a monolithic
chunk of memory, and modify it to either:  allocate all the memory it's going
to want in this block in a single call; or to treat blocks of memory obtained
by separate calls to sbrk as if they were not contiguous (which they may not
be).  This was one of the problems I ran into modifying device-independent troff
to run under VMS, so even Kernighan has been known to take advantage of this
"feature (?)" of UNIX.