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!linus!decvax!wanginst!infinet!cgf
From: cgf@infinet.UUCP (Chris Faylor)
Newsgroups: net.micro.pc
Subject: Problems with Microsoft C V 3.0 memory routines
Message-ID: <279@infinet.UUCP>
Date: Mon, 4-Nov-85 09:02:43 EST
Article-I.D.: infinet.279
Posted: Mon Nov  4 09:02:43 1985
Date-Received: Fri, 8-Nov-85 03:40:13 EST
Reply-To: cgf@infinet.UUCP (Chris Faylor)
Organization: Infinet Inc., Andover, MA
Lines: 30

{}
Has anyone out there noticed any problems with the realloc routine
distributed with Microsoft C?  It seems to sometimes leave garbage
in the middle of a reallocated block of memory if the newly malloc'ed
block overlaps the old.

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.

In general, it seems that malloc does not behave well if you have
the misfortune of running out of memory.  I have not completely
corroborated it, but it looks like a pointer somewhere gets
screwed up.  After returning a NULL (indicating that there isn't
enough contiguous memory for the request) it appears that it will
sometimes start allocating new memory over previously allocated blocks.

Anybody else seen this?
-- 
			-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