[comp.lang.c] farrealloc

ray@vax1.acs.udel.EDU (Thomas Ray) (05/03/90)

     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

clifton@egsner.cirr.com (Clifton Bean) (05/04/90)

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

jhallen@wpi.wpi.edu (Joseph H Allen) (05/04/90)

In article <1990May4.003455.1602@egsner.cirr.com> clifton@egsner.cirr.com (Clifton Bean) writes:
>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

>>     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

You might consider using the MS-DOS memory allocator:

#include <dos.h>

void far *falloc(unsigned long size)
{
void far *block=0;
if(0xfff00000&size) return 0;
_BX=size&15?size/16+1:size/16;
_AH=0x48;
geninterrupt(0x21);
__emit__(0x73,2,0x28,0xc0);	/* Clear AX if Carry is set */
*(1+(unsigned *)&block)=_AX;
return block;
}

void ffree(void far *block)
{
_ES=FP_SEG(block);
_AH=0x49;
geninterrupt(0x21);
}

void far *frealloc(void far *block,unsigned long size)
{
if(0xfff00000&size) return 0;
_ES=FP_SEG(block);
_BX=size&15?size/16+1:size/16;
_AH=0x4a;
geninterrupt(0x21);
__emit__(0x73,2,0x28,0xc0);	/* Clear AX if Carry is set */
*(1+(unsigned *)&block)=_AX;
return block;
}

Be forewarned, however:  These are not compatible with turbo C's farm functions.
Also, presumably MS-DOS is slower than turbo C, so only use these if you're
not allocating very often.  Also, these have only been tested in small & tiny
models.

-- 
jhallen@wpi.wpi.edu (130.215.24.1)