home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / amiga / programmer / 5433 < prev    next >
Encoding:
Text File  |  1996-08-05  |  3.3 KB  |  72 lines
  1. Newsgroups: comp.sys.amiga.programmer
  2. Path: chang.unx.sas.com!walker
  3. From: walker@chang.unx.sas.com (Doug Walker)
  4. Subject: Re: Ceck out this bug. What the *** is SASC/6.56 doing?
  5. Sender: news@unx.sas.com (Noter of Newsworthy Events)
  6. Message-ID: <Do9Fy0.HGp@unx.sas.com>
  7. Date: Thu, 14 Mar 1996 13:53:59 GMT
  8. X-Nntp-Posting-Host: chang.unx.sas.com
  9. References: <1120.6643T91T406@login.eunet.no> <874.6644T381T2315@login.eunet.no> <4i17ga$doo@btmpjg.god.bel.alcatel.be> <885.6646T9T693@login.eunet.no>
  10. Organization: SAS Institute Inc.
  11.  
  12. In article <885.6646T9T693@login.eunet.no>,
  13. Patrick Hanevold <patrick.hanevold@login.eunet.no> wrote:
  14. >
  15. >>>Tryed "Stack check" and all that. No difference.
  16. >>>Anyway, the default stack is 4K isnt it?
  17. >>>Cant think of anything using that additional 1K.
  18. >>>Dont want it global. Allocate it myself now.
  19. >>>
  20. >>OpenScreenTags() need stack too!! Together with the already used stack
  21. >>by _main, and the 3252 bytes of main(), you only have about 800 bytes
  22. >>left for OpenScreenTags(), might be too small. Stackcheck will not
  23. >>find this, because stackcheck does not know the stack-usage of
  24. >>OpenScreenTags().
  25. >
  26. >OpenScreenTags() doesnt crash. exit(0) does.
  27. >I guess it maby could mess up so exit(0) would crash.
  28. >Stach check should be smart enough to fail if there was too litle stack left.
  29. >I would guess none of the OS calls would need more then 4K since thats the
  30. >default stack size.
  31.  
  32. With a stack trash, it is very possible that a stack overrun would not be
  33. detected until cleanup time.
  34.  
  35. Stack check fails if there is not enough stack to execute the CURRENT FUNCTION.
  36. If all functions called by the function in question are also compiled with
  37. stack checking, you're 100% covered.  In practice, your program is going to
  38. have to make system calls and library calls, neither of which are going to have
  39. stack checking code compiled in.
  40.  
  41. Stack EXTENSION, on the other hand, allows for a "fudge factor".  If the 
  42. remaining stack size at function entry time is less than the global long
  43. _STKNEED, a new stack extent is allocated.  The default _STKNEED value
  44. is 400 bytes.
  45.  
  46. There is no way for the compiler to know how much stack the system calls you
  47. make are going to use, so it is not reasonable to expect the stack checking
  48. code to catch this situation.  If you think you know, use stack extension and
  49. statically initialize the global long _STKNEED to the amount the system 
  50. routines are going to need.
  51.  
  52. Ultimate in speed  ==>  No stack checking/no stack extension
  53. Ultimate in safety ==>  Stack extension with a large _STKNEED value
  54. Decent compromise  ==>  Stack checking
  55.  
  56. Pick one.  In the end, it's up to YOU to make sure your code has enough stack
  57. to run.  Don't assume that just because a tool is available, you get to quit
  58. thinking.
  59.  
  60. By the way, you could also set your program's stack requirements by statically 
  61. initializing the global long __stack to a multiple of four bytes indicating how
  62. much stack you want.  The SAS/C startup code will allocate a new stack for you 
  63. if the one you are given is too small.  For this program, you could probably
  64. set it to 8K and have no problems (assuming you've been failing with a 4k stack.)
  65.  
  66. -- 
  67.   *****     
  68.  *|_o_o|\\     Doug Walker   walker@unx.sas.com  
  69.  *|. o.| ||                
  70.   | o  |//     Any opinions are mine, not those of SAS Institute, Inc.
  71.   ====== 
  72.