4 ms·

Classic Mac OS applications had 32 kb of stack. Desk Accessories had 8. Much of my effort to fixing Working Software's QuickLetter went towards reducing stack

Classic Mac OS applications had 32 kb of stack. Desk Accessories had 8. Much of my effort to fixing Working Software's QuickLetter went towards reducing stack consumption. My predecessor had apparently not read the fine manual. We spent a lot if money to purchase MacCLint but it overflowed the stack by megabytes and so corrupted the heap. The author wasnt receptive of my advice to remove all its recursion, he asserted rcursion is necessary for compiler-like programs. Recursive algorithms di not require recursive implementations. The pricedure fir converting recursion to iteration is documented by Robert Sedgewick in "Algorithms". Really you do have a stack but its not the runtime stack.

eutectic 11y ago
In a compiler recursion is typically used for walking Abstract Syntax Trees, and the recursion depth is usually similar to the scope nesting depth. I find it hard to believe that this could add up to megabytes for normal code.
- MichaelCrawford 11y ago
  A common problem in QuickLetter before I fixed it was that it had very large local (stack) variables - big arrays and structs. My first fix was to malloc() anything larger than a couple dozen bytes. MacCLint was a piece of work; I would be unsurprised were it to have local variables that were megabytes in size. That is I don't know the depth of recursion but I do know that it blew out the 32 kB limit by megabytes. MacCLint is also the reason why I always use explicit returns in C-like languages. It would crash - which on Mac OS System 7 would drop my box into MacsBug - if I just fell off the end of a void function. Dave Johnson, the owner of Working Software, had already advised me to use explicit returns because he once used a compiler that generated incorrect machine code if he didn't do so. Even without buggy tools explicit returns are handy for setting breakpoints. Some debuggers enable you to break just before return even if you fall off the end but not all do.
  - netheril96 11y ago
    > MacCLint is also the reason why I always use explicit returns in C-like languages. It would crash - which on Mac OS System 7 would drop my box into MacsBug - if I just fell off the end of a void function. Isn't falling off a void function the same as returning from it?
    - MichaelCrawford 11y ago
      Yes.
Someone 11y ago
It comes 'a bit' late, but couldn't you increase stack size by calling SetApplLimit before calling MaxApplZone? And of course, initially, classic Mac OS didn't have 32kB of stack on original hardware. It didn't even have 32kB available to applications.
- MichaelCrawford 11y ago
  I started at WSI about seven months before System 7 was introduced. At the time the documented limit was 32 kB. Yes applications could call SetApplLimit but Desk Accessories could not, QuickLetter's stack was on top of the application's stack. We had no control over that. I expect the System always ensured that DAs could have 8 kB of stack on top of whatever the application had; that is, app+DA defaulted to 40 kB. MacCLint was such a skanky program I don't think it would have done it a whole lot of good to increase the stack.
  - Someone 11y ago
    Aha! I didn't get your problems were with a desk accessory.

eutectic 11y ago

In a compiler recursion is typically used for walking Abstract Syntax Trees, and the recursion depth is usually similar to the scope nesting depth. I find it hard to believe that this could add up to megabytes for normal code.

MichaelCrawford 11y ago
A common problem in QuickLetter before I fixed it was that it had very large local (stack) variables - big arrays and structs. My first fix was to malloc() anything larger than a couple dozen bytes. MacCLint was a piece of work; I would be unsurprised were it to have local variables that were megabytes in size. That is I don't know the depth of recursion but I do know that it blew out the 32 kB limit by megabytes. MacCLint is also the reason why I always use explicit returns in C-like languages. It would crash - which on Mac OS System 7 would drop my box into MacsBug - if I just fell off the end of a void function. Dave Johnson, the owner of Working Software, had already advised me to use explicit returns because he once used a compiler that generated incorrect machine code if he didn't do so. Even without buggy tools explicit returns are handy for setting breakpoints. Some debuggers enable you to break just before return even if you fall off the end but not all do.
- netheril96 11y ago
  > MacCLint is also the reason why I always use explicit returns in C-like languages. It would crash - which on Mac OS System 7 would drop my box into MacsBug - if I just fell off the end of a void function. Isn't falling off a void function the same as returning from it?
  - MichaelCrawford 11y ago
    Yes.

Someone 11y ago

It comes 'a bit' late, but couldn't you increase stack size by calling SetApplLimit before calling MaxApplZone? And of course, initially, classic Mac OS didn't have 32kB of stack on original hardware. It didn't even have 32kB available to applications.

MichaelCrawford 11y ago
I started at WSI about seven months before System 7 was introduced. At the time the documented limit was 32 kB. Yes applications could call SetApplLimit but Desk Accessories could not, QuickLetter's stack was on top of the application's stack. We had no control over that. I expect the System always ensured that DAs could have 8 kB of stack on top of whatever the application had; that is, app+DA defaulted to 40 kB. MacCLint was such a skanky program I don't think it would have done it a whole lot of good to increase the stack.
- Someone 11y ago
  Aha! I didn't get your problems were with a desk accessory.