堆栈分配有很多相关的问题是可以理解的
What and where are the stack and heap?
Why is there a limit on the stack size?
但是在各种 *nix 机器上我可以发出 bash 命令
ulimit -s unlimited
或 csh 命令
set stacksize unlimited
这如何改变程序的执行方式？对程序或系统性能是否有任何影响（例如，为什么这不是默认设置）？
如果涉及更多系统细节，我主要关心的是在 x86_64 硬件上运行的 Linux 上使用 GCC 编译的程序。
【问题讨论】：
当您调用函数时，会在堆栈上分配一个新的“命名空间”。这就是函数可以具有局部变量的方式。随着函数调用函数，函数又调用函数，我们不断在堆栈上分配越来越多的空间来维护这种深层的命名空间层次结构。
为了限制使用大量堆栈空间的程序，通常通过ulimit -s 设置限制。如果我们通过ulimit -s unlimited 取消该限制，我们的程序将能够继续为不断增长的堆栈占用 RAM，直到最终系统完全耗尽内存。
int eat_stack_space(void) { return eat_stack_space(); }
// If we compile this with no optimization and run it, our computer could crash.
通常，使用大量堆栈空间是偶然的，或者是非常深的递归的症状，可能不应该过多地依赖堆栈。因此堆栈限制。
对性能的影响很小，但确实存在。使用time 命令，我发现消除堆栈限制将性能提高了几分之一秒（至少在 64 位 Ubuntu 上）。
【讨论】：
gcc-4.7 -O3 你的 smash_the_stack 例子是尾递归的被翻译成一个无限循环，没有任何调用。
gcc -O0 编译它。
堆栈大小可以确实是无限的。 _STK_LIM 是 默认值，_STK_LIM_MAX 是每个架构都不同的东西，从 include/asm-generic/resource.h 可以看出：
/*
* RLIMIT_STACK default maximum - some architectures override it:
*/
#ifndef _STK_LIM_MAX
# define _STK_LIM_MAX RLIM_INFINITY
#endif
从这个例子中可以看出，泛型值是无限的，其中RLIM_INFINITY 在泛型情况下再次定义为：
/*
* SuS says limits have to be unsigned.
* Which makes a ton more sense anyway.
*
* Some architectures override this (for compatibility reasons):
*/
#ifndef RLIM_INFINITY
# define RLIM_INFINITY (~0UL)
#endif
所以我想真正的答案是 - 堆栈大小可能会受到某些架构的限制，那么无限的堆栈跟踪将意味着 _STK_LIM_MAX 定义的任何内容，如果它是无限的 - 它是无限的。有关将其设置为无限的含义以及它可能产生的影响的详细信息，请参阅另一个答案，它比我的要好。
【讨论】：
ulimit -s unlimited 让堆栈无限增长。
如果您通过递归编写程序，这可能会防止您的程序崩溃，特别是如果您的程序不是尾递归（编译器可以“优化”那些），并且递归深度很大。
【讨论】：