home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / sys / mac / programm / 18854 < prev    next >
Encoding:
Internet Message Format  |  1992-11-24  |  1.5 KB
  1. Path: sparky!uunet!cs.utexas.edu!uwm.edu!spool.mu.edu!agate!NewsWatcher!user
  2. From: werner@soe.berkeley.edu (John Werner)
  3. Newsgroups: comp.sys.mac.programmer
  4. Subject: Re: Pointers to function and UnloadSeg
  5. Followup-To: comp.sys.mac.programmer
  6. Date: 24 Nov 1992 03:48:28 GMT
  7. Organization: UC Berkeley School of Education
  8. Lines: 23
  9. Distribution: world
  10. Message-ID: <werner-231192194549@128.32.157.31>
  11. References: <1992Nov23.002629.3444@ccu1.aukuni.ac.nz>,<keith-231192142230@kip-15.taligent.com> <1992Nov24.011014.9522@alw.nih.gov>
  12. NNTP-Posting-Host: 128.32.157.31
  13.  
  14. In article <1992Nov24.011014.9522@alw.nih.gov>, Chris Spiral Catfish Tate
  15. wrote:
  16. > 
  17. > In a related vein, what about calling UnloadSeg() on code segments that are
  18. > in your function's calling chain, but not in the same segment?  Are all
  19. > those code segments locked reliably?
  20.  
  21. I think you're asking whether it's safe to call UnloadSeg on segments that
  22. are in the current call tree/stack, but that don't contain the function
  23. currently executing.  If so, don't; this is a recipe for disaster.  Imagine
  24. that a funciton calls UnloadSeg on its caller's segment, then does
  25. something that purges memory.  When it returns, its caller won't be there,
  26. and there will be a spectacular (and probably hard to debug) crash.
  27.  
  28. >Might this sort of thing interact oddly with setjmp() and longjmp() in
  29. >THINK C 5?
  30.  
  31. It would interact oddly with just about _anything_, including setjmp and
  32. longjmp.
  33.  
  34. --
  35. John Werner                         werner@soe.berkeley.edu
  36. UC Berkeley School of Education     510-642-9651
  37.