home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / sys / mac / programm / 18551 < prev    next >
Encoding:
Text File  |  1992-11-17  |  2.7 KB  |  59 lines
  1. Newsgroups: comp.sys.mac.programmer
  2. Path: sparky!uunet!pageworks.com!world!eff!sol.ctr.columbia.edu!usc!elroy.jpl.nasa.gov!ames!data.nas.nasa.gov!taligent!kip-16.taligent.com!user
  3. From: keith@taligent.com (Keith Rollin)
  4. Subject: Re: faulty ANSI in Think C 5.0?
  5. Message-ID: <keith-171192135605@kip-16.taligent.com>
  6. Followup-To: comp.sys.mac.programmer
  7. Sender: usenet@taligent.com (More Bytes Than You Can Read)
  8. Organization: Taligent
  9. References: <1992Nov16.211648.23619@math.ucla.edu> <1ebg9lINNi8e@terminator.rs.itd.umich.edu>
  10. Date: Tue, 17 Nov 1992 22:01:26 GMT
  11. Lines: 46
  12.  
  13. In article <1ebg9lINNi8e@terminator.rs.itd.umich.edu>,
  14. potts@oit.itd.umich.edu (Paul Potts) wrote:
  15. > 
  16. > In article <1992Nov16.211648.23619@math.ucla.edu> dchopp@vicente.math.ucla.edu (David Chopp) writes:
  17. > >I'm curious if others have run into similar problems as I regarding using
  18. > >some ANSI subroutines in Think C 5.0.2 with TCL.  In particular, I have
  19. > >trouble using strcpy, strcmp, sprintf, to name a few.  I have found them
  20. > >to be sporadic in working properly and I'm wondering if I'm doing something
  21. > >wrong.  For example, in one object, I'll have two methods each using strcpy
  22. > >in them (all in the same file).  In one context, it works perfectly, in the
  23. > >other it fails to copy.  The arguments being passed are all correct (I've
  24. > >checked them several times).  
  25. > 
  26. > I'd say it is most likely that there is a problem in your program. I've
  27. > used sprintf, strcpy, strcmp, etc. and had them work fine. 
  28. > 
  29. > Some things to consider: are you testing the arguments under the source-level
  30. > debugger, or at runtime under MacsBug? The source-level debugger and the
  31. > low-level debugger can show different things. Under the source debugger
  32. > sometimes memory is better initialized, pointers tend not to penalize you
  33. > for writing to stray addresses, etc. Whenever I've had problems using
  34. > the string routines, they were caused by some other part of my code which
  35. > was trashing memory at runtime.
  36.  
  37. Another thing that occurs to me is that there could be problems if the
  38. strings are data members of handle-based objects, and the ANSI routines are
  39. in an unloaded code segment. If that's so, then a call like:
  40.  
  41.     strcmp(fMyString, "Test string");
  42.  
  43. can fail. This is because calling strcmp() will cause the code segment
  44. containing it to be loaded. This loading could cause the object owning
  45. fMyString to move AFTER its address has been taken and placed on the stack.
  46.  
  47. If this is the problem, there are at least three solutions:
  48.  
  49. 1) lock the object containing fMyString.
  50. 2) make sure the ANSI library is in a resident segment
  51. 3) copy fMyString into a local variable (oops! this requires access to
  52. strcpy!
  53.    infinite page fault has occured -- shutting down...)
  54.  
  55. -----
  56. Keith Rollin
  57. Phantom Programmer
  58. Taligent, Inc.
  59.