0

If there is no memory left on the heap malloc will return NULL.

Is the behaviour on stack overflow defined in C?

Wikipedia suggests it's likely to cause a segfault, at least in the case of infinite recursion, but could something else happen?

Also in many managed environments, the runtime does not allow you to create arrays on the stack. Does that mean we should avoid it in native code too to guard against stack overflow, at least when the size of the array is determined at run time?

George Simms
  • 3,520
  • 3
  • 17
  • 33
  • 2
    The C specification does really say anything about "stack" or "heap". So running out of space on either heap or stack is unspecified. – Some programmer dude Nov 01 '14 at 16:09
  • @JoachimPileborg But the specification says that `malloc()` can return `NULL` if it's unable to allocate. That's the expected result if you run out of whatever memory `malloc()` uses (we can choose to call that the "heap"). The point of this question is that there's nothing analogous for being unable to allocate memory for local variables in a function. – Barmar Nov 01 '14 at 16:12
  • It's not possible for any environment to prohibit creating arrays on the stack. Arrays and non-array variables are just memory, there's no way for the environment to know how the memory will be used. – Barmar Nov 01 '14 at 16:14
  • @Barmar yes I know. My question was about whether it was a bad idea or not – George Simms Nov 01 '14 at 16:19
  • As long as you keep your local variables to reasonable sizes (a few KB per function call), you should be fine. – Barmar Nov 01 '14 at 20:32

2 Answers2

2

When you have a stack overflow, you are writing in unallocated memory. The behaviour on writing in unallocated memory is undefined, but it will probably make your program crash.

Vincent
  • 618
  • 3
  • 9
  • 1
    So the operating system sets aside a fixed amount of memory for the stack, and then on stack overflow the stack pointer wanders off the end of this memory and attempts to push new data onto the stack will cause an attempt to write to memory to which the process is potentially not allowed access? – George Simms Nov 01 '14 at 16:16
2

Does that mean we should avoid it in native code too to guard against stack overflow, at least when the size of the array is determined at run time?

Why would you avoid it? I would not avoid it because one benefit stack declared arrays have as compared to dynamic ones is that you don't have to bother with memory management issues (e.g., no need to free). This is big plus.

In rare cases if the array you want is too big and won't fit on stack, you can use dynamic arrays. There are some estimates on stack sizes too, on Windows for example in Visual Studio default stack size is 1MB. You can consider this. This size can also be increased if I am not wrong.

gmoniava
  • 18,228
  • 5
  • 33
  • 74
  • "in Visual Studio default stack size is 1MB... This size can also be increased if I am not wrong." Is this controlled within the process' binary then? Also is this 1MB per thread or between threads? – George Simms Nov 01 '14 at 16:24
  • @GeorgeSimms: http://stackoverflow.com/questions/1825964/c-c-maximum-stack-size-of-program some info here. You can read up more details about that elsewhere – gmoniava Nov 01 '14 at 19:47