Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!usenet.ins.cwru.edu!shasta!trier From: trier@shasta.scl.cwru.edu (Stephen Trier) Newsgroups: comp.sys.ibm.pc Subject: Re: Need help with Turbo C "farmalloc" Summary: It's not a bug, it's a feature! Keywords: Turbo C farmalloc Message-ID: <1990Feb9.161156.6173@usenet.ins.cwru.edu> Date: 9 Feb 90 16:11:56 GMT References: <4100@mace.cc.purdue.edu> Reply-To: trier@SCL.CWRU.Edu (Stephen Trier) Organization: Smith Undergrad Lab, CWRU, Cleve. OH Lines: 32 X-Post-Machine: shasta.scl.cwru.edu In article <4100@mace.cc.purdue.edu> you write: >I've been trying to use the "farmalloc" routine with Turbo C 2.0. I am >trying to allocate numerous small units (e.g., 6 - 20 bytes with each >call). I don't know the number or size of the units in advance -- it is >data dependent -- so I can't use "farcalloc". > >The problem that I'm having is that when I request 1-8 bytes, I'm given >16. When I request 9-16, I'm given 32 bytes...and so on. This causes >me to run out of memory long before I should. (This is determined by >calling "farcoreleft" after each "farmalloc" call.) This is normal for most C compilers. In fact, K & R describe the need for rounded-up allocation units. (At least, they did in the first edition.) Paragraph-size allocation sounds a bit large, but not all that surprising. All that is guaranteed when using any malloc derivative is that you will get at least as many bytes as you need. Giving you more is up to the compiler. The most likely cause is the overhead involved in C's dynamic memory system. C uses a linked list of memory blocks, both allocated and free. This means that when you ask for 4 bytes of storage, you may get another 4 or 8 bytes of malloc-list data as part of the bargain. (Borland's example program on page 113 of the Reference Guide shows an 8-byte overhead for farmalloc.) If the overhead involved is too great, you will have to use your own allocator of some kind. Consider the possibilities of allocating from an array, or from a linked list of arrays. <=> Stephen Trier seldon!sct@skybridge.SCL.CWRU.Edu sct@po.CWRU.Edu {sun,att,decvax}!cwjcc!skybridge!trier