Documented that buffer can't grow if REJECT used

diff --git a/flex.1 b/flex.1
index a99f86689fd38798989cce68db899921d33e06d7..54b6a60cc790d22f09bb7f3d851130b51feae58f 100644 (file)
--- 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