Xref: utzoo comp.databases:5802 comp.lang.c:28423
Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!cs.utexas.edu!texbell!vector!egsner!clifton
From: clifton@egsner.cirr.com (Clifton Bean)
Newsgroups: comp.databases,comp.lang.c
Subject: Re: farrealloc() bug in Turbo C
Summary: Reposting of Problem Reported in comp.lang.c
Keywords: fix needed
Message-ID: <1990May4.003455.1602@egsner.cirr.com>
Date: 4 May 90 00:34:55 GMT
References: <6377@vax1.acs.udel.EDU>
Sender: Clifton M. Bean
Distribution: usa
Organization: Central Iowa (Model) Railroad, Dallas, Tx.
Lines: 46

In article <6377@vax1.acs.udel.EDU> ray@vax1.acs.udel.EDU (Thomas Ray) writes:
>
>     The function farrealloc() in Turbo C is described as ``Adjusts allocated
>block in far heap....  Blocks larger than 64K can be allocated''.  The
>problem is that it only works for blocks of up to 64K.  I called their
>technical support, and they were not aware of the problem, but upon
>examining the source code, said that in fact it would not work for blocks
>larger than 64K because it first allocates another block with farmalloc(),
>and then uses memmove() to move the data from the old block.  However,
>memmove() only handles up to 64K and they forgot to code in the case of more
>than 64K.  Stupid!
>
>    The technician suggested that I write my own farrealloc() using
>farmalloc() and memmove().  It sounded good at the time, but later I realized
>that I would need to know how big the old block was in order to move it
>properly (when going to a larger block).  Since that information is not
>passed to the function, it must be gotten from the system and I don't know
>how to do it.  There is currently a discussion on this problem in comp.lang.c
>under the subject heading of malloc/free.  I called back to the technical
>support to discuss the matter further, but the guy I got was very rude and
>told me he didn't have time to look into it.
>
>     So, does anyone have a piece of code that can do a farrealloc() in
>Turbo C, or can anyone write and test such a function?  It would be nice
>to have a farrealloc() that would try to expand the block before resorting to
>the malloc()/memmove() combination.  This will be especially critical for
>large blocks because there will very likely not be enough room to make another
>block before discarding the old one.  If you send me a fix by email, I will
>summarize and post the responses.
>
>                             Tom Ray
>                       University of Delaware
>                  School of Life & Health Sciences
>                      Newark, Delaware  19716
>                         ray@vax1.udel.edu
>                           302-451-2753

I have seen mail from quite a few people at Informix posted here, and since
I use Informix-Turbo and I am thinking about upgrading to Online, I thought
I would post this article from comp.lang.c and see what the good people
could do for us.
-- 
*******************************************************************************
Clifton M. Bean                          USENET: clifton@lodestar.lonestar.org
Page & Addison, P.C., Dallas, TX           UUCP: ...!egsner!lodestar!clifton
Work Phone: (214) 960-0933 (9-6 CDT)         OR: ...!texbell!lodestar!clifton