Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!caen!hellgate.utah.edu!peruvian.utah.edu!msmith
From: msmith%peruvian.utah.edu@cs.utah.edu (Matthew Smith)
Newsgroups: comp.lang.c
Subject: Re: Does TC's farrealloc have a bug?
Message-ID: <1991Jun21.124738.5383@hellgate.utah.edu>
Date: 21 Jun 91 18:47:38 GMT
References: <1991Jun19.083945.8921@ucthpx.uct.ac.za> <6574@ns-mx.uiowa.edu> <1991Jun21.152700.25820@doc.ic.ac.uk>
Organization: University of Utah CS Dept
Lines: 20

In article <1991Jun21.152700.25820@doc.ic.ac.uk> pj@doc.ic.ac.uk (Paul Jarvis) writes:
>
>I have recently had a report of problems using huge far pointers and allocating
>and freeing memory. The problem appeared to be that the free process did not
>work hence memory got lost. The compiler was Turbo C (sorry version not known).
>Changing to Borland C++ compiler with identical code - i.e. the same program
>no problem. My conclusion is that there may be some problems with allocating
>large memory chuncks but I sure don't want to try to prove it.
>                           Paul
>                        (pj@doc.ic.ac.uk)

Do a farcoreleft() call before doing your farmalloc(), then do another
farcoreleft(), then call farfree() and do a farcoreleft().  Watch how your
values go.  The final farcoreleft() number should match the first farcoreleft()
number.

Matt Smith
msmith@peruvian.utah.edu
University of Utah
Department of Computer Science