|Input buffer overflow in lex firstname.lastname@example.org (1993-01-04)|
|Re: Input buffer overflow in lex... email@example.com (John R. Levine) (1993-01-05)|
|Re: Input buffer overflow in lex... firstname.lastname@example.org (1993-01-05)|
|Re: Input buffer overflow in lex... email@example.com (1993-01-06)|
|Re: Input buffer overflow in lex... firstname.lastname@example.org (1993-01-08)|
|From:||email@example.com (Vern Paxson)|
|Organization:||Lawrence Berkeley Laboratory, Berkeley CA|
|Date:||Tue, 5 Jan 1993 18:30:07 GMT|
John R. Levine <firstname.lastname@example.org> writes:
> Well, the short answer is that you lose. No version of lex checks for
> token buffer overflow, although it is less destructive in flex than it is
> in lex. This can be called a lex design error, though it's hard to
> check for overflow without making the lexer a lot slower.
Let me clarify a bit. flex does detect token buffer overflow and
generates a fatal run-time error when it occurs. It can do so cheaply
because such overflow can only occur when new characters are being read
into the input buffer. That's a rare operation in a flex scanner because
input is block-oriented.
> The other possibility is to use start states to build the string
Hear hear! This is in general a much better approach, as it also provides
a natural way to deal with escape sequences and continued strings.
Vern Paxson email@example.com
Systems Engineering ucbvax!ee.lbl.gov!vern
Lawrence Berkeley Laboratory (510) 486-7504
Return to the
Search the comp.compilers archives again.