home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / os / msdos / programm / 9191 < prev    next >
Encoding:
Text File  |  1992-09-09  |  2.3 KB  |  48 lines
  1. Newsgroups: comp.os.msdos.programmer
  2. Path: sparky!uunet!usc!news.service.uci.edu!ucivax!megatek!hollen
  3. From: hollen@megatek.UUCP (Dion Hollenbeck)
  4. Subject: Re: malloc overhead?
  5. In-Reply-To: rwed@hal.gnu.ai.mit.edu's message of 9 Sep 92 02: 21:23 GMT
  6. Message-ID: <HOLLEN.92Sep9082649@peg.megatek.UUCP>
  7. Sender: hollen@megatek.com (Dion Hollenbeck)
  8. Organization: Megatek Corporation, San Diego, California
  9. References: <DAVIS.92Sep8201040@pacific.mps.ohio-state.edu> <27648@life.ai.mit.edu>
  10. Date: Wed, 9 Sep 1992 16:26:49 GMT
  11. Lines: 35
  12.  
  13. >>>>> On 9 Sep 92 02:21:23 GMT, rwed@hal.gnu.ai.mit.edu (N7YVM) said:
  14.  
  15. N7YVM> In article <DAVIS.92Sep8201040@pacific.mps.ohio-state.edu> davis@pacific.mps.ohio-state.edu  (John E. Davis) writes:
  16.  
  17. >important. If I malloc some space of length size, how much additional overhead
  18.  
  19. N7YVM> I wondered about this too.. without trying to remember too many details,
  20. N7YVM> I noticed all my mallocs in TurboC were displayed as pointers in the form
  21. N7YVM> segment:0008.. The word at segment:0000 was the size of my block+8,
  22. N7YVM> the word at segment:2 looked like a pointer to another block.. the others
  23. N7YVM> I couldnt determine.. 
  24.  
  25. N7YVM> Id be interested in finding out what this information is..
  26.  
  27. I have done LOTS of malloc'ed memory debugging with linked lists in
  28. the large model in Turbo C and the address is ALWAYS segment:0008.
  29. This comes from literally thousands of times looking at returned
  30. malloc'ed pointers.  I would be very confident of saying that the
  31. overhead for a malloc in large model is 8 bytes.
  32.  
  33. BTW, this brings up a helpful hint.  Do not ever neglect to include
  34. <alloc.h> when using malloc().   This is no problem in the 64k data
  35. models because the type of malloc() is assumed to be int - 16 bits and
  36. a near character pointer is 16 bits, the malloc'ed value being
  37. returned in the AX register.  In the large data models, malloc()
  38. returns a 32 bit segment:offset pointer in AX, DX and if you have not
  39. declared malloc() to be char far *, then the next instruction after
  40. the call to malloc is CDW (convert word to double word) and your
  41. result is ALWAYS 0000:0008 and the first time you use the pointer, you
  42. piss all over your interrupt vectors.
  43.  
  44. -- 
  45. Dion Hollenbeck       UUCP: {uunet, ucsd, sun}!megatek!hollen
  46.                       INTERNET:            hollen@megatek.com
  47. Megatek Corporation  9645 Scranton Rd.  San Diego, Ca.  92121
  48.