Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site infinet.UUCP
Path: utzoo!watmath!clyde!cbosgd!ihnp4!houxm!whuxl!whuxlm!akgua!gatech!seismo!harvard!bbnccv!bbncca!wanginst!infinet!cgf
From: cgf@infinet.UUCP (Chris Faylor)
Newsgroups: net.micro.pc
Subject: Re: Problems with Microsoft C V 3.0 memory routines
Message-ID: <280@infinet.UUCP>
Date: Tue, 19-Nov-85 10:41:46 EST
Article-I.D.: infinet.280
Posted: Tue Nov 19 10:41:46 1985
Date-Received: Sat, 23-Nov-85 03:39:12 EST
References: <279@infinet.UUCP> <649@dicomed.UUCP>
Reply-To: cgf@infinet.UUCP (Chris Faylor)
Organization: Infinet Inc., Andover, MA
Lines: 37

In article <649@dicomed.UUCP> papke@dicomed.UUCP (Kurt Papke) replies:
> ...
>I have used the realloc() routine quite a bit and have never experienced
>the problem you describe.
>
>>Looking at the code, it seems pretty obvious that there will be times
>>when this will definitely happen.  It will always fail if you try
>>to increase the size of a block from, say, 10 bytes to 16 bytes, and
>>there are 6 free bytes immediately preceding the original ten.
>>What happens is that realloc first frees the block it is trying to
>>expand, then malloc sets aside the only available 16 bytes, placing
>>a memory size header in the middle of the original 10 byte block.
>>Then realloc copies the old block, header and all, up 6 bytes.
>
>Could be.  How do you know this without the sources to the run-time
>library ??

Excuse me.  I should have said "disassembled listing" instead of
"code".

>No, although most of the code I've written with 3.0 has no choice but
>to roll over and die when it runs out of heap !!

I guess I just like to live in the fast lane.  My application attempts
to do some cleanup and recovery when it runs out of heap !!

I have received mail which indicates that these bugs existed in UNIX
Version 7 malloc and in XENIX and VENIX.  So I suppose there is a
real good possibility that Microsoft ported the bugs to MSDOS, too.

-- 
			-cgf-

I feel more like I do now than I did when I first got here.

		decvax!wanginst!infinet!cgf
		emacs!infinet!cgf@cca-unix.ARPA