🚀 go-pugleaf

>>>>> On 9 Sep 92 02:21:23 GMT, rwed@hal.gnu.ai.mit.edu (N7YVM) said:

N7YVM> In article <DAVIS.92Sep8201040@pacific.mps.ohio-state.edu> davis@pacific.mps.ohio-state.edu  (John E. Davis) writes:

>important. If I malloc some space of length size, how much additional overhead

N7YVM> I wondered about this too.. without trying to remember too many details,
N7YVM> I noticed all my mallocs in TurboC were displayed as pointers in the form
N7YVM> segment:0008.. The word at segment:0000 was the size of my block+8,
N7YVM> the word at segment:2 looked like a pointer to another block.. the others
N7YVM> I couldnt determine.. 

N7YVM> Id be interested in finding out what this information is..

I have done LOTS of malloc'ed memory debugging with linked lists in
the large model in Turbo C and the address is ALWAYS segment:0008.
This comes from literally thousands of times looking at returned
malloc'ed pointers.  I would be very confident of saying that the
overhead for a malloc in large model is 8 bytes.

BTW, this brings up a helpful hint.  Do not ever neglect to include
<alloc.h> when using malloc().   This is no problem in the 64k data
models because the type of malloc() is assumed to be int - 16 bits and
a near character pointer is 16 bits, the malloc'ed value being
returned in the AX register.  In the large data models, malloc()
returns a 32 bit segment:offset pointer in AX, DX and if you have not
declared malloc() to be char far *, then the next instruction after
the call to malloc is CDW (convert word to double word) and your
result is ALWAYS 0000:0008 and the first time you use the pointer, you
piss all over your interrupt vectors.

-- 
Dion Hollenbeck       UUCP: {uunet, ucsd, sun}!megatek!hollen
                      INTERNET:            hollen@megatek.com
Megatek Corporation  9645 Scranton Rd.  San Diego, Ca.  92121