home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / sys / mac / programm / 14555 < prev    next >
Encoding:
Text File  |  1992-08-26  |  1.3 KB  |  35 lines
  1. Newsgroups: comp.sys.mac.programmer
  2. Path: sparky!uunet!cs.utexas.edu!sun-barr!ames!data.nas.nasa.gov!taligent!lsr.taligent.com!user
  3. From: lsr@taligent.com (Larry Rosenstein)
  4. Subject: Re: dereferencing Handles( was Re: incrementation differences/THINK C 4.0 vs. 5.0)
  5. Message-ID: <lsr-260892112200@lsr.taligent.com>
  6. Followup-To: comp.sys.mac.programmer
  7. Sender: usenet@taligent.com (More Bytes Than You Can Read)
  8. Organization: Taligent, Inc.
  9. References: <1992Aug24.221630.4730@Csli.Stanford.EDU> <1992Aug25.150911.19008@bnr.ca> <1992Aug25.174228.17601@natinst.com>
  10. Date: Wed, 26 Aug 1992 18:24:47 GMT
  11. Lines: 22
  12.  
  13. In article <1992Aug25.174228.17601@natinst.com>, stepan@natinst.com (Stepan
  14. Riha) wrote:
  15. > 
  16. > However a thing to be carefull about is code of the form:
  17. > 
  18. >     Handle    h;
  19. > 
  20. >     *h = foo();
  21. > 
  22. > where foo() causes memory to be relocated.  If the LHS is evaluated first, it
  23. > might be incorrect once foo is called.  The correct way to write this would be
  24.  
  25. And you not only have to consider whether the code in foo() can relocate
  26. memory, but whether the call to foo() itself might relocate memory.  This
  27. can happen if foo() is in a different segment from the caller, and that
  28. segment has to be brought into memory or moved.  (That implies that some
  29. calls to foo() might not move memory, but others could.)
  30.  
  31. Larry Rosenstein
  32. Taligent, Inc.
  33.  
  34. lsr@taligent.com
  35.