Is there a explicit limit on the main thread stack size?

[HelpfulPerson]

I was wondering this, because I have a structure in a fairly large project I work on consistently that seems to grow exponentially by the day. I don't know if in C the stack grows automatically if you reach the limit or if you have to handle that somehow yourself. If it helps, I run my programs on Windows 7 with the IDE Code::Blocks and GCC. Just in case it is compiler-dependent/system-dependent.

[grumpy]

Stack has nothing to do with C. The C standard is silent on the topic of stack size (in fact, it doesn't mention a stack at all).

The notion of stack itself is actually system dependent. Modern operating systems normally manage stack (memory used as scratch space by a running program or process) and heap (memory that a program is permitted to allocate dynamically) via quotas. The quota for stack is tuned to find a balance, considered sensible by the operating system designer, between available resources (the available physical and virtual memory gives a hard upper limit on quotas for both stack and heap size), the needs of typical user and system programs, and the number of user and system programs that an OS needs to host (i.e. execute) at once. Depending on operating system, the quotas can be tweaked by the system administrator on a system-wide basis, a group (of users) basis, and even on a per-process basis (processes with sufficient privilege can change their quotas to suit their needs, and control quotas of other processes).

Generally speaking, stack needed by a program is only loosely related (at best) to project size or program size.

[HelpfulPerson]

Generally speaking, stack needed by a program is only loosely related (at best) to project size or program size.

Well, I know my project size wouldn't matter. I'm just saying I keep all my data in a main structure that functions as a storage device for all my functions. I was wondering what might happen if I unintentionally go over that quota you mentioned in your post.

[grumpy]

If your program (or process) attempts to go over a quota, it would typically not be allowed to start - the process of launching the executable would fail. Some program launchers would adjust quotas and make subsequent attempts to re-launch, but those sorts of things are unusual.

From a basic architectural perspective, I'd query why your program needs to keep all its data in a global structure in the first place. Such techniques implicitly limit the ability of a program to evolve, usually before any problems with stack quota or the like.

[HelpfulPerson]

If your program (or process) attempts to go over a quota, it would typically not be allowed to start - the process of launching the executable would fail. Some program launchers would adjust quotas and make subsequent attempts to re-launch, but those sorts of things are unusual.

From a basic architectural perspective, I'd query why your program needs to keep all its data in a global structure in the first place. Such techniques implicitly limit the ability of a program to evolve, usually before any problems with stack quota or the like.

Well it's easier than having to keep track of a lot of data for each function separately. Most of the biggest pieces of data are dynamically allocated in linked lists and the sort though.

[grumpy]

Well it's easier than having to keep track of a lot of data for each function separately.

That's the common rationale employed. The headaches come later .....

[rcgldr]

Most compilers have a compile time option to set the stack size.

[iMalc]

Firstly, a description of this kind has nothing to do with the stack: "consistently that seems to grow exponentially by the day".
That's a rough description of a memory leak, which would no doubt involve heap memory.
Don't go throwing in buzzwords like "exponentially" which is almost certainly untrue in this case. More plausibly it grows somewhat "linearly".

Most importantly though, how did you measure this? I'm guessing Task Manager? I'll let you in on a well-known fact... Task Manager doesn't actually give you anything that is a good measure of how much memory is taken up by your application. As a developer, you need to be using "Process Explorer" from Windows Sysinternals: Documentation, downloads and additional resources. No Windows developer should be without it.

[rcgldr]

I have a structure ... that seems to grow exponentially by the day.

"consistently that seems to grow exponentially by the day". ... That's a rough description of a memory leak.

I think he means that some structure is growing day by day.

Stack space is pre-allocated at run time before main is called. On some operating systems / compilers it's possible to increase the size of the stack, but typically if a "non-standard" stack size is needed, it's done via a compile time option.

If there is only a single instance of this structure in main(), an alternative to using stack space is to declare the structure "static", so that it's pre-allocated and initialized in the same area as global variables, often called the "data segment". It won't be using stack space, but it will still use memory space, so it's possible that the program could run out of memory at run time if the program is also allocating memory (such as malloc()).

[ledow]

If you were that worried, you'd just make it a malloc'd variable. It literally takes a handful of lines of code and ensures that - if the machine has enough RAM - you'll always have enough space for it.

Those people who worry about the stack-size don't see that the end solution is to either static it or malloc it, and both end up taking from global heap rather than the stack. Why worry about it when you could just have malloc'd it in the first place (and then even stood a chance of erroring out nicely if you were running in some ridiculously-low-memory environment that can't even do that allocation)?

If stack space worries you, at all, in any way, in even a "well, in the future" kind of way - don't use it. Just malloc stuff instead. What do you lose? Nothing.

If you ever hit stack limits, there is very little you can do anyway - as pointed out you can change the size of the stack but that makes your code hard to port (do you know how to change stack size on every type of compiler / machine and put it in your Makefiles?) and still doesn't guarantee that it will even do anything (some machines, you can't change the stack size to an arbitrary value and so it will just override you anyway). So pre-empt hitting them and the second you think to yourself "Wow, that's getting large", stop allocating it from the stack.

I can't say I've ever written a program that hit a stack limit except on Palm handhelds (some of which had ludicrously limited stacks and horrendous compiler workarounds to get around them), and that used so little stack that I never even thought it would be a problem, it wasn't a problem on ANY other kind of machine, and in the end I just restructured stuff to be dynamic as much as possible.

Don't worry about it. When you do need to worry about it, you have to do the EXACT thing that you're trying to avoid - make the allocations not come from the stack but from the heap. So pre-empt it and just allocate it from the heap now and save yourself the effort of even counting up how many bytes it would take on the stack.

[HelpfulPerson]

If you were that worried, you'd just make it a malloc'd variable. It literally takes a handful of lines of code and ensures that - if the machine has enough RAM - you'll always have enough space for it.

I thought about that later, that I could just create the structure as a single node on the heap just as easily. It wouldn't really change how I declare it, except I would have to add a handful of lines to handle allocating it. Then pass the structure as a pointer to the structure to the rest of the functions as needed, just as I have been doing.

I think he means that some structure is growing day by day.

That's what I meant. As far as using task manager goes, I do use it for rough estimates from time to time. I assumed it only took into account heap memory though, as I observed it going up and down in tune to malloc() and free() calls. If it doesn't give me the data I think it does, I would be glad to use another( preferably free ) software to use as a developer. Also, as far as the word exponentially goes, I'm sorry if it was taken the wrong way. I was just using that word to describe how the structure is rapidly growing when I add new features.

[iMalc]

As far as using task manager goes, I do use it for rough estimates from time to time. I assumed it only took into account heap memory though, as I observed it going up and down in tune to malloc() and free() calls. If it doesn't give me the data I think it does, I would be glad to use another( preferably free ) software to use as a developer. Also, as far as the word exponentially goes, I'm sorry if it was taken the wrong way. I was just using that word to describe how the structure is rapidly growing when I add new features.

Task Manager more or less shows you how much of the application's memory space is not currently paged out to disk. When you malloc memory, and thereafter use it, the OS caching usually wont chuck it straight out to the page file, and when you free, the C runtime might sometimes give some blocks back to the OS. It's all very rough and typically nowhere near reliable enough for leak detection.
Its going up or down often says more about the rest of the stuff running on the PC than what your app is using.

[Elysia]

If stack space worries you, at all, in any way, in even a "well, in the future" kind of way - don't use it. Just malloc stuff instead. What do you lose? Nothing.

Absolutely everything. Especially in C.
Heap memory isn't free. It costs more to allocate small chunks to overhead and most important, you have to free it! None of this applies to stack variables.