home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / sys / mac / programm / 14744 < prev    next >
Encoding:
Text File  |  1992-08-30  |  1.5 KB  |  34 lines
  1. Path: sparky!uunet!charon.amdahl.com!pacbell.com!att!linac!pacific.mps.ohio-state.edu!cis.ohio-state.edu!magnus.acs.ohio-state.edu!usenet.ins.cwru.edu!agate!dog.ee.lbl.gov!csa1.lbl.gov!sichase
  2. From: sichase@csa1.lbl.gov (SCOTT I CHASE)
  3. Newsgroups: comp.sys.mac.programmer
  4. Subject: malloc in Think C
  5. Date: 30 Aug 92 20:52:35 GMT
  6. Organization: Lawrence Berkeley Laboratory - Berkeley, CA, USA
  7. Lines: 20
  8. Distribution: na
  9. Message-ID: <25873@dog.ee.lbl.gov>
  10. Reply-To: sichase@csa1.lbl.gov
  11. NNTP-Posting-Host: 128.3.254.196
  12. News-Software: VAX/VMS VNEWS 1.3-4   
  13.  
  14. Sorry to ask such a newbie question.  I'm sure that this has been discussed
  15. many times.  But I never paid close attention until it came up for me yesterday.
  16. Due to a "data segment too big" message when trying to use the debugger,
  17. I had to dynamically allocate a 10K array, like this:
  18.  
  19. char *array;
  20. array = malloc(10000*sizeof(char));
  21.  
  22. My question is:  Do I have to worry about memory moving around?  Will
  23. array continue to point to the correct data regardless of what toolbox 
  24. routines I use which scramble memory?  Do I have to do this with a handle
  25. instead or does Think's implementation of malloc lock the memory for me? 
  26.  
  27. -Scott 
  28. --------------------
  29. Scott I. Chase            "The question seems to be of such a character
  30. SICHASE@CSA2.LBL.GOV        that if I should come to life after my death
  31.                 and some mathematician were to tell me that it
  32.                 had been definitely settled, I think I would
  33.                 immediately drop dead again."      - Vandiver
  34.