home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / sys / amiga / programm / 12910 < prev    next >
Encoding:
Text File  |  1992-08-31  |  2.9 KB  |  87 lines
  1. Newsgroups: comp.sys.amiga.programmer
  2. Path: sparky!uunet!gatech!concert!sas!mozart.unx.sas.com!jamie
  3. From: jamie@cdevil.unx.sas.com (James Cooper)
  4. Subject: Re: Yet Another SAS/C thread
  5. Originator: jamie@cdevil.unx.sas.com
  6. Sender: news@unx.sas.com (Noter of Newsworthy Events)
  7. Message-ID: <BtupwA.176@unx.sas.com>
  8. Date: Mon, 31 Aug 1992 14:07:22 GMT
  9. References:  <la2ipoINNsk6@pollux.usc.edu>
  10. Nntp-Posting-Host: cdevil.unx.sas.com
  11. Organization: SAS Institute Inc.
  12. Lines: 73
  13.  
  14.  
  15. In article <la2ipoINNsk6@pollux.usc.edu>, addison@pollux.usc.edu (Richard Addison) writes:
  16. >I have a few questions I haven't seen asked about SAS/C version 6.
  17. >
  18. >Does lmk still change all file names to lower case?  [This was actually
  19. >something fairly recent, like 5.10b but not 5.10a.]
  20.  
  21. Yes, the 5.10b LMK changed names to lower case, but this was a side
  22. effect of a bugfix.  All versions of LMK prior to 5.10b were CASE
  23. SENSITIVE on target names.  In 5.10b, LMK changes all names to lower
  24. case before checking.  Unfortunately, it propogated the changed name
  25. to the output, instead of using the original.
  26.  
  27. Yes, this has been fixed.
  28.  
  29. >Does the builtin memcmp() work in all cases?  It generally creates code
  30. >like this:
  31. >
  32. >       bra.s   $2
  33. >$1:    cmp.b   (A0)+,(A1)+
  34. >$2:    dbeq    D0,$1
  35. >
  36. >The problem that could occur is that the Zero condition flag could be
  37. >true before the branch instruction.  This would cause memcmp() to
  38. >report that the two regions of memory as being equal regardless of
  39. >reality.
  40.  
  41. Hmm... unless I'm mistaken, the decrement is done before the flag is
  42. checked, which takes care of the problem...
  43.  
  44. >Does cpr support debugging multiple tasks more reliably?  [I've worked
  45. >around the problems by detaching all but one task.]
  46.  
  47. Yes, CPR is a *lot* more reliable, in a lot of different areas.
  48.  
  49. >Has the compiler/cpr bug with being unable to recognize some symbols
  50. >within some static functions been fixed?
  51.  
  52. CPR should have no further problems with static functions.
  53.  
  54. >On large executables, cpr could complain about invalid debugging
  55. >information.  Has this been fixed?
  56.  
  57. The whole debug format has changed for V6.0, so these problems should be
  58. gone for good.
  59.  
  60. >Do the cpr watch commands support the same sorts of display controls
  61. >as the dump commands?
  62.  
  63. Sorry, there wasn't time to implement this feature, though it may make
  64. it in a future version... :-)
  65.  
  66. >Does cpr remember the size and placement of the informational windows
  67. >when you close and reopen them?
  68.  
  69. No, but it still recognises the command line switches to set the size
  70. and placement of the window.
  71.  
  72. Remembering the window position, etc. is still on the Enhancement list,
  73. though.  At least this made it into the Editor this time... :-)
  74.  
  75. >I've already sent in my order for the update, so these questions are
  76. >mostly for curiosity.  Thanks.
  77.  
  78. You're welcome.
  79.  
  80. -- 
  81. ---------------
  82. Jim Cooper
  83. (jamie@unx.sas.com)                             bix: jcooper
  84.  
  85. Any opinions expressed herein are mine (Mine, all mine!  Ha, ha, ha!),
  86. and not necessarily those of my employer.
  87.