Xref: utzoo alt.msdos.programmer:1189 comp.sys.ibm.pc:44010 Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!purdue!mentor.cc.purdue.edu!mace.cc.purdue.edu!afc From: afc@mace.cc.purdue.edu (Greg Flint) Newsgroups: alt.msdos.programmer,comp.sys.ibm.pc Subject: Need help with Turbo C "farmalloc" Keywords: Turbo C farmalloc Message-ID: <4100@mace.cc.purdue.edu> Date: 9 Feb 90 06:15:40 GMT Followup-To: comp.sys.ibm.pc Organization: Purdue University Lines: 27 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.) The manual says that I should get "n" bytes when I request "n" bytes, but I seem to be getting memory in paragraphs -- and 2x what I think I'd need even if it had to give them to me in 16 byte units. I called Bourland support -- what a waste of $'s that was -- and was told that "probably" memory was given out in paragraphs and that "probably" it was supposed to work that way -- regardless of what the manual says. In short, I got no info from Bourland. Does anyone have a patch or a code around for this problem? I know that I could do one big "farmalloc" and write my own "little malloc", but speed is important and I'd prefer not have to execute "C" code if assembler code (or a patch) is available. Besides, writing "little malloc" seems a lot like re-inventing the wheel. ------------------------------------------------------------------------------- Greg Flint Math G-169 (317) 494-1787 UUCP: purdue!klaatu.cc!afc Purdue Univ. Purdue University INTERNET: afc@klaatu.cc.purdue.edu Computing Ctr. West Lafayette, IN 47907 BITNET: flint@purccvm.bitnet