Stack: I'm back!

😃 😃 😃 😃 😃 😃 😃 😃 😃

If you are using /link or /lgo on the command line then the simple way to increase the stack size is to add /stack n where n is the new stack size in megabytes.

'The reports of my death have been greatly exaggerated' (c), Mr.Stack.

I have not seen or heard from anyone who was thankful to discover painfully the existence of stack, the devilry feature from ancient ages hell, at least no one needed it for the last 40 years. Why developers still persistently keeping it ? With 64bit we got memory limits formally increased by 4 billion times and I ran my 64bit code and got hit again by the same damn thing I suffered a lot with 32 bits, may be with just a bit larger bar.

You may find that the problems are less severe in the next release since I understand that changes have been made that may help.

I will make enquires about this issue.

Dan,

No stack, then no subroutines, no functions, no parameters. OK, call it something else, but it's still there. Stack limits? Now there's a different problem and perhaps you can solve it for yourself. Just don't use it up for no good reason: passing local arrays.

Provided you don't overflow, you can use it all. In the words of the Eagles: Take it to the limit, take it to the limit Take it to the limit one more time

Sometimes just a few extra bytes is all you need.

Incidentally, once you got into Clearwin+ you used to be in the Hotel California, because you could check out but you could never leave. Dang, now where's my guitar?

Quoted from LitusSaxonicum Hotel California...because you could check out but you could never leave. Eddie, what is there not served in that Hotel California since 1969? In my Hotel California all is being served, the whole stack of it, you can check some day being around. I'd gladly exchange with Silverfrost our stacks. Don't want to checkout or leave by the way 😃

Dan,

My understanding is stack overflow can be caused by a variety of reasons.

1. is local variables overflow the stack size limitation, while
2. there are many other errors that can corrupt the stack and it's expected size. Ignoring the vast possibilities associated with 2), the solution for 1) is to avoid local arrays.

With /64, local arrays can get much bigger, so my solution is to make all local (especially automatic) arrays ALLOCATE arrays, possibly placing them in a module to better manage them. (local allocate arrays are automatically de-allocated on return, except for pointer arrays, which can be a major source of memory leakage)

You should not be lazy with local arrays as they are a major source of problems. This is especially so in multi-threading, where large private arrays can quickly cause a stack overflow, as well as performance problems with repeated memory allocation.

Making the stack larger is a temporary patch to mask the problem, while managing these arrays with ALLOCATE is a much better solution.

John

The next release of FTN95 will treat local arrays as though they were automatic arrays. This means that any arrays other than very small ones will be allocated from a 'virtual' stack that automatically grows when needed and has a very large upper limit.

Hopefully the problem of stack overflow, particularly when processing large amounts of legacy code, will go away (at least for 64 bit FTN95). For new code John's advice makes good sense.

Wowwowowowwww....that's even more then i'd realistically hoped for. This company shows that it has no lack of visionaries and does not afraid to innovate.