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]