Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!cbatt!ihnp4!chinet!ignatz
From: ignatz@chinet.UUCP (ignatz)
Newsgroups: net.lang.c,net.unix
Subject: Microport and SCO Xenix Memory Managment Problems
Message-ID: <646@chinet.UUCP>
Date: Mon, 20-Oct-86 03:52:37 EDT
Article-I.D.: chinet.646
Posted: Mon Oct 20 03:52:37 1986
Date-Received: Tue, 21-Oct-86 23:14:08 EDT
Organization: chinet, Public Access UN*X, Chicago, IL
Lines: 60
Keywords: sbrk, brk, Microport, SCO Xenix
Xref: watmath net.lang.c:10777 net.unix:9637

Memory allocation problems exist with both Microport and the SCO Xenix
compiler, kids.  Just ran into it tonight when trying to get a program
working that heavily depends on using sbrk().  FYI, the
traditional version of sbrk() will extend the current data space by
the requested byte increment, returning the old 'break', or
end-of-data-address, value.  This memory was contiguous, and could
also be released to the OS by using a negative increment in another
sbrk() call.  This call, and the related brk() call, comprise the OS
interface to basic memory managment that is used in more general-purpose
packages such as malloc().  A common use of the direct sbrk()
interface is to provide direct stack managment in such programs as the
shell; you get a memory access violation on a stack push, then do an
sbrk() to extend the stack (if you can), and continue processing.

The Microport version of sbrk() works properly--or at least, the
documentation claims it does--in the small memory configuration.
HOWEVER, in the Large memory model, it's got the following exotic
behavior (the following from the Microport documentation):  For *any* 
sbrk() call with a positive increment, **all** of the rest of the
addresses in the current segment are skipped, and the entire
incremental allocation is provided in the *next* segment.  Not only
that, but you are explicitly warned that addresses will not be
necessarily contiguous with previous sbrk() call values, because of
this--there may be 'holes' for the skipped memory--and that return
values may not necessarily have address relationships with the current
break value.

The Xenix System V manual is less blatant about the whole thing, but
it's there, too.  It states that in large model programs, if the
requested increment is greater than the number of unallocated bytes
remaining in the current segment, then it skips to the next segment
for the entire request.  While this is a bit nicer than the Microport
default of always skipping, it still leaves that bloody non-contiguous
window.  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.  In both cases, handling of the sbrk() call with a
negative increment reflects similar deviations from what was
previously considered 'normal' Unix(Tm, and all that) behavior.

Now, I understand the problems inherent with dealing with a segmented
architecture and memory management--I was fighting this, with a MMU,
in 1981.  STILL--this behavior is both a terrible deviation from the
original behavior of the Unix sbrk(), and a violation of the current
proposed IEEE Std. 1003.1.  Now, granted, the other bible--The Sys V
Interface Document, from AT&T--seems to beg the issue of brk() and
sbrk()  (As I remember--my SVID docs are at work right now, and I'm at
home; corrections will, I am sure, be provided!!); but nevertheless,
it seems obvious to me that if you're going to try and say it's Unix,
then it ought to provide downward compatibility in the behavior of
already-extant system services.  And the standard, while not accepted,
is still pretty reliable.

The upshot?  SCO and Microport had better get on the bandwagon and
provide routines that work.  I'm sorry, I know it may not be easy, but
then nobody ever said it was going to be easy, did they?...
-- 
				Dave Ihnat
				Analysts International Corporation
				aicchi!ignatz or wlcrjs!ignatz
				(w) 882-4673  (h) 784-4544