Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!caip!elbereth!rutgers!lll-crg!lll-lcc!pyramid!amdahl!andrew
From: andrew@amdahl.UUCP (Andrew Sharpe)
Newsgroups: net.lang.c,net.unix
Subject: Re: Microport and SCO Xenix Memory Managment Problems
Message-ID: <4004@amdahl.UUCP>
Date: Tue, 21-Oct-86 13:48:41 EDT
Article-I.D.: amdahl.4004
Posted: Tue Oct 21 13:48:41 1986
Date-Received: Wed, 22-Oct-86 04:49:56 EDT
References: <646@chinet.UUCP>
Organization: Amdahl Corp, Sunnyvale CA
Lines: 26
Keywords: sbrk, brk, Microport, SCO Xenix
Xref: watmath net.lang.c:10789 net.unix:9644

In article <646@chinet.UUCP>, ignatz@chinet.UUCP (ignatz) writes:
> Memory allocation problems exist with both Microport and the SCO Xenix
> compiler, kids   ....
> Also, as for the Microport version, the result of sbrk(0) is
> not truly indicative of anything more than a marker for the previous
> memory location.

This is not quite correct. The System V/286 version (for sbrk(0) in large
model) will return a memory location that is the _beginning_ of the next
segment, so that the pointer may be remembered and used later after an
sbrk(+n). 

Now, Microport is supposed to be using System V/286. This is how it works
in the System V/286 kernel, available from AT&T. If Microport has changed
the behavior of brk() and sbrk(), that's a shame, because we worked very
hard (in conjunction with AT&T) to make the memory management of
SystemV/286 act (as much as possible) like the VAX. This was one of the
charters of the 286 sanctioned port.


-- 
Andrew Sharpe              !{ihnp4,decwrl}!amdahl!andrew
--------------------------------------------------------
The opinions expressed above do not reflect the views of
the employees, nor the management, of Amdahl Corporation
--------------------------------------------------------