是什么限制了c中嵌套循环的数量？

编辑:对于那些寻找问题答案的人,如标准所述,标准限制了编译时嵌套循环的数量.在运行时,这是一个不同的问题,因为唯一的限制是程序段的大小.

解决:我在构建过程中看得太早.c文件进一步应用于它的预处理.关闭后续步骤.

我对使用perl从应用生成发音规则的语言生成的c代码有疑问.在本质上,输入是一个庞大的发音规则例外字典.代码充满了gotos,直到其中一个异常字典达到23K规则为止.

代码基本上是不可读的但我已经设法在删除看似第6200个嵌套循环之后编译c代码:

for (dictionionary1=seed1;dicitonary1

gcc和xlC都能够处理这些,但是aCC 3.73(在H11.23 PA RISC上)正在发挥作用. 

Compiling /home/ojblass/exception_dictionary_a.c...
Loading the kernel...
Pid 18324 killed due to text modification or page I/O error
/bin/ksh: 28004 Bus error(coredump)
*** Error exit code 138


我找到了这个链接并尝试了许多建议的修复但没有成功.

由于遗留原因,我必须编译为32位(它使用32位库,我没有64位对应的).  

maxdsiz = 256 MB (x10000000) tried up to 4 GB
maxssiz = 16 MB (x1000000) tried up to 100MB
maxtsiz = 256 MB (x10000000) tried up to 1 GB


编译器设置的任何建议或aCC 3.73的文档的良好链接？我淹没在搜索结果中.  

我编写了一个解决方法,将字典分成两部分,导致dictionary_an.c和dictionary_az.c.我不得不触摸一些核心逻辑,我感觉不舒服以便将其拉下来,我希望能够退回原始配置.


1> Michael Burr..：
哇 - 我知道这对你没有帮助,但是嵌套6199级深度远远超过C或C++要求(C90为15,C99为127,C++为256).

我很好奇的是这个东西的运行情况 - 如果你的字典是任何大小的,循环迭代次数必须是天文数字.假设每个字典大小为10:(10 ^ 6199)是相当大的数字.即使每个字典只有2个项目,(2 ^ 6199)也令人印象深刻.

        
@objblass:不,递归算法没问题.重要的只是"语法"嵌套深度,基本上解析函数时解析器的深度.无论何时调用另一个函数,嵌套深度都变得无关紧要(因为您正在调用的函数是单独解析的,从嵌套深度0开始).所以限制仅适用于在单个函数内可以直接嵌套在每个其他循环中的循环数.