CVSROOT:        /sources/m4
Module name:    m4
Changes by:     Eric Blake <ericb>      06/09/29 12:26:07

Index: doc/m4.texinfo
===================================================================
RCS file: /sources/m4/m4/doc/m4.texinfo,v
retrieving revision 1.54
retrieving revision 1.55
diff -u -b -r1.54 -r1.55
--- doc/m4.texinfo      28 Sep 2006 04:22:33 -0000      1.54
+++ doc/m4.texinfo      29 Sep 2006 12:26:06 -0000      1.55
@@ -609,7 +609,13 @@
 @itemx [EMAIL PROTECTED]
 Artificially limit the nesting of macro calls to @var{NUM} levels,
 stopping program execution if this limit is ever exceeded.  When not
-specified, nesting is limited to 1024 levels.
+specified, nesting is limited to 1024 levels.  A value of zero means
+unlimited; but then heavily nested code could potentially cause a stack
+overflow.  @var{NUM} can have an optional scaling suffix.
[EMAIL PROTECTED] FIXME - need a node on what scaling suffixes are supported 
(see
[EMAIL PROTECTED] [info coreutils 'block size'] for ideas), and need to consider
[EMAIL PROTECTED] whether builtins should also understand scaling suffixes:
[EMAIL PROTECTED] eval, mpeval, perhaps format
 
 The precise effect of this option might be more correctly associated
 with textual nesting than dynamic recursion.  It has been useful
@@ -695,10 +701,12 @@
 Restrict the size of the output generated by macro tracing or by
 @code{dumpdef} to @var{NUM} characters per string.  If unspecified or
 zero, output is unlimited.  @xref{Debug Levels}, for more details.
[EMAIL PROTECTED] can have an optional scaling suffix.
 @comment FIXME - should we add a debuglen macro that can alter this
 @comment setting on the fly?  Also, should we add an option that
 @comment controls whether output strings are sanitized with escape
 @comment sequences, so that dumpdef is truly one line per macro?
[EMAIL PROTECTED] FIXME - see comment on --nesting-limit about NUM.
 
 @item -t @var{NAME}
 @itemx [EMAIL PROTECTED]


Reply via email to