home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / sys / mac / programm / 19993 < prev    next >
Encoding:
Text File  |  1992-12-18  |  3.2 KB  |  65 lines
  1. Newsgroups: comp.sys.mac.programmer
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!usc!rpi!batcomputer!cornell!rochester!udel!sbcs.sunysb.edu!csws10.ic.sunysb.edu!rhorn
  3. From: rhorn@csws10.ic.sunysb.edu (Robert Horn)
  4. Subject: Re: Fix : ThinkC app won't run standalone (bug in smart link!?)
  5. Message-ID: <1992Dec17.214202.12978@sbcs.sunysb.edu>
  6. Sender: usenet@sbcs.sunysb.edu (Usenet poster)
  7. Nntp-Posting-Host: csws10.ic.sunysb.edu
  8. Organization: State University of New York at Stony Brook
  9. References: <steve.herman-161292132205@128.158.4.199> <1992Dec16.215017.16222@usl.edu> <1992Dec17.143701.19170@sernews.raleigh.ibm.com>
  10. Date: Thu, 17 Dec 1992 21:42:02 GMT
  11. Lines: 52
  12.  
  13. In article <1992Dec17.143701.19170@sernews.raleigh.ibm.com> crg@rocky.raleigh.ibm.com (Chuck Grissom) writes:
  14. >In article <1992Dec16.215017.16222@usl.edu>, pvl1779@usl.edu (Leach Phuong V) writes:
  15. >|> 
  16. >|> First thanks to those who responded.
  17. >|> 
  18. >|> The problem seems to be in the linker.  I turned the "smart link" option
  19. >|> off when building the application, and it runs fine now.
  20. >|> 
  21. >|> The app was crashing on a sprintf() call.  Earlier calls worked fine, but
  22. >|> at some point in the program, sprintf() got stepped on and no longer
  23. >|> worked.  It seems to me that the "smart" linker has a possible bug.
  24. >|> Does this seem like a reasonable assumption to you?
  25. >|> 
  26. >|> Go figure,
  27. >|> Robb
  28. >
  29. >Well, bugs in the linker are possible...but...many, many times I have heard
  30. >a C programmer claim that the bug in his program must be due to a compiler bug
  31. >only to find after further debugging that it's in his code after all.  As for
  32. >me, I assume every bug is MINE unless I can point to the exact problem in the
  33. >compiler/linker.  If it is such a problem, you should be able to reproduce it
  34. >with very simple code.  Otherwise, keep looking for those pointer errors!
  35. >
  36. >Chuck
  37.  
  38. Recently I was writing an 'XTCL' for Alpha (my shareware fee will be sent just
  39. as soon as I find a job (I can no longer use the excuse that I'm a starving
  40. college student) :), and using sprintf compiled with 4 byte ints and 
  41. A4 addressing and the beastie was periodicly crashing (I forget what
  42. the exact sequence of events was, but it was reproducable) in sprintf
  43. (actually, it would hang for a while, then crash...). I eventually wrote
  44. my own sprintf routine (at least, as much of sprintf as I was using), and
  45. the 'XTCL' worked perfectly fine (or at least hasn't crashed yet).
  46.  
  47. I assumed at the time that I was just doing something mindbogglingly
  48. stupid (so mindbogglingly stupid that I would never see it), but it's
  49. also possible that there is a subtle bug in sprintf, which might be causing
  50. the problems above as well. (No, I haven't traced through the entirety
  51. of sprintf using MacsBug, but I did check my parameters on the way
  52. into the routine, and they seemed perfectly fine (no dereferenced 
  53. handles, (locked or unlocked), the result string was long enough
  54. for the sprintfed stuff and all that), and my_min_sprintf worked,
  55. so I wouldn't rule out a bug in sprintf).
  56.  
  57. Robb (an entirely different Robb than any other Robb mentioned
  58.       previously in this post)
  59.  
  60.  
  61.  
  62. -- 
  63. rhorn@ic.sunysb.edu         Never choose a college because it has a duckpond.
  64. $@`                                             Send me hate mail, I love it.
  65.