From: Vern Paxson <vern@ee.lbl.gov>
Date: Mon, 29 Nov 1993 17:13:22 +0000 (+0000)
Subject: Documented that buffer can't grow if REJECT used
X-Git-Tag: flex-2-5-5b~323
X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=18a7d069a1aef814f454c6343e231ac847854d99;p=flex

Documented that buffer can't grow if REJECT used
---

diff --git a/flex.1 b/flex.1
index a99f866..54b6a60 100644
--- a/flex.1
+++ b/flex.1
@@ -1617,7 +1617,7 @@ scanner.  If you give the flag twice, you will also get comments regarding
 features that lead to minor performance losses.
 .IP
 Note that the use of
-.I REJECT
+.B REJECT
 and variable trailing context (see the Bugs section in flex(1))
 entails a substantial performance penalty; use of
 .I yymore(),
@@ -2189,7 +2189,7 @@ feature will be to automatically add rules to eliminate backing up).
 .I Variable
 trailing context (where both the leading and trailing parts do not have
 a fixed length) entails almost the same performance loss as
-.I REJECT
+.B REJECT
 (i.e., substantial).  So when possible a rule like:
 .nf
 
@@ -2957,6 +2957,13 @@ Ideally the scanner should dynamically resize the buffer in this case, but at
 present it does not.
 .PP
 .I
+input buffer overflow, can't enlarge buffer because scanner uses REJECT -
+the scanner was working on matching an extremely large token and needed
+to expand the input buffer.  This doesn't work with scanners that use
+.B
+REJECT.
+.PP
+.I
 fatal flex scanner internal error--end of buffer missed -
 This can occur in an scanner which is reentered after a long-jump
 has jumped out (or over) the scanner's activation frame.  Before