Is there a limit for the total variables size on the stack?

While coding should we consider some limit on the total size of variables created on the stack? If yes, on what basis should we decide it? Is it dependent on OS, Memory Availability etc? Are there any compiler options which can check this?

A开发者_开发知识库ny pointers in the direction will also be helpful.

This is one of the less user-friendly areas of the C standard.

It's all entirely implementation-dependent, and pretty much impossible to do "properly". The C standard does not guarantee what automatic variables you can define without blowing the stack, or what happens when you do, or any way of measuring stack use or specifying stack size, or any way of detecting that you're about to run out of stack, perhaps with unpredictable results. The standard doesn't even mention the word "stack".

So, you should be mindful of how much stack you're using, but how much is too much could be a few k or even less on an embedded system, and 1MB or more on a desktop system. On Windows you barely care about stack - as long as you aren't putting vast arrays on it, or recursing to a depth equal to the size of some array or list, then you'll be fine. On limited systems it's not necessarily a good idea to put even a filename on the stack. But if you only ever put built-in types and tiny arrays and structs on the stack, and if you only ever recurse to depth log N, then again you'll be fine pretty much anywhere. Hopefully you'll get an obvious crash if you're not fine, but you can't be sure.

The most critical time is when you're porting code to a new system - if you can't estimate that stack use is "not very much", then you need to test carefully. For this reason, if you're worried about portability to limited systems, then you must be conservative with stack use. As for what "conservative" means, it sort of depends what "limited" means, but if you're interested in mobile-phone levels of "limited", then the size of a filename is about where you might be thinking, "should this be on the heap instead?", but of course context matters a lot: if your file-handling code has 10 layers, modifying the filename at each layer, then you don't want to be doing that on the stack. If it only has a couple of layers, and you know it won't be called by code that has anything big on the stack already, you can probably get away with it.

Although I say "phones", modern smartphones are closer to the desktop model of "oh, just use what you need, it'll be fine". If you're programming for something PIC-like (and insist on writing C), then basically forget about portable assumptions, and track exactly what stack you're using compared with what's available.

I don't think I remember ever encountering a protected OS that works the way 0x6adb015 describes, so you can't even say "it doesn't matter whether I use stack or heap, they all come from the same pool in the end". They don't, necessarily. The two main models I've encountered are:

• Stack address space is assigned up front (and perhaps committed, perhaps not), so there's a hard limit how much stack you can use, and any more than that your program crashes even if there's memory left.

• Stack is extended dynamically, so you can keep using stack until you run out of memory.

So, stack could be a more limited resource than heap. As Mitch Wheat says, compiler (or linker) options can vary the size of this region, check your manual for details. The OS may also provide runtime options, such as ulimit. I'd add that thread APIs can let you specify the stack size for a new thread. Again, though, it's completely implementation-dependent.

Usually, your process's memory map will have a heap (malloc'ed memory) and stack (automatic memory). The heap is assigned on the map's top memory, and the stack grows to the bottom. In no case the stack pointer and the heap pointer should collide.

So in short, the stack size is related to your process's memory map.

┌──────
│ stack
│  │
│  ▼
├╌╌╌╌╌╌
│
│ free space
│
├╌╌╌╌╌╌
│  ▲
│  │
│ heap
└──────

This should be also true on embedded systems.