=over =item ${^MAX_NESTED_EVAL_BEGIN_BLOCKS} This variable determines the maximum number C/C or C/C block nesting that is allowed. This means it also controls the maximum nesting of C statements as well. The default of 1000 should be sufficiently large for normal working purposes, and if you must raise it then you should be conservative with your choice or you may encounter segfaults from exhaustion of the C stack. It seems unlikely that real code has a use depth above 1000, but we have left this configurable just in case. When set to C<0> then C blocks inside of C or C are forbidden entirely and will trigger an exception which will terminate the compilation and in the case of C will throw an exception, or in the case of C return the error in C<$@> as usual. Consider the code perl -le'sub f { eval "BEGIN { f() }"; } f()' each invocation of C will consume considerable C stack, and this variable is used to cause code like this to die instead of exhausting the C stack and triggering a segfault. Needless to say code like this is unusual, it is unlikely you will actually need to raise the setting. However it may be useful to set it to 0 for a limited time period to prevent BEGIN{} blocks from being executed during an C. Note that setting this to 1 would NOT affect code like this: BEGIN { $n += 1; BEGIN { $n += 2; BEGIN { $n += 4 } } } The reason is that BEGIN blocks are executed immediately after they are completed, thus the innermost will execute before the ones which contain it have even finished compiling, and the depth will not go above 1. In fact the above code is equivalent to BEGIN { $n+=4 } BEGIN { $n+=2 } BEGIN { $n+=1 } which makes it obvious why a ${^MAX_EVAL_BEGIN_DEPTH} of 1 would not block this code. Only C's executed inside of an C or C (possibly via C) are affected. =back