home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / compiler / 2086 < prev    next >
Encoding:
Internet Message Format  |  1993-01-06  |  1.7 KB
  1. Path: sparky!uunet!spool.mu.edu!wupost!emory!ogicse!das-news.harvard.edu!spdcc!iecc!compilers-sender
  2. From: vern@daffy.ee.lbl.gov (Vern Paxson)
  3. Newsgroups: comp.compilers
  4. Subject: Re: Input buffer overflow in lex...
  5. Keywords: lex
  6. Message-ID: <93-01-013@comp.compilers>
  7. Date: 5 Jan 93 18:30:07 GMT
  8. Article-I.D.: comp.93-01-013
  9. References: <93-01-009@comp.compilers> <93-01-010@comp.compilers>
  10. Sender: compilers-sender@iecc.cambridge.ma.us
  11. Reply-To: vern@daffy.ee.lbl.gov (Vern Paxson)
  12. Organization: Lawrence Berkeley Laboratory, Berkeley CA
  13. Lines: 26
  14. Approved: compilers@iecc.cambridge.ma.us
  15.  
  16. John R. Levine <johnl@iecc.cambridge.ma.us> writes:
  17. > Well, the short answer is that you lose.  No version of lex checks for
  18. > token buffer overflow, although it is less destructive in flex than it is
  19. > in lex.  This can be called a lex design error, though it's hard to
  20. > check for overflow without making the lexer a lot slower.
  21.  
  22. Let me clarify a bit.  flex does detect token buffer overflow and
  23. generates a fatal run-time error when it occurs.  It can do so cheaply
  24. because such overflow can only occur when new characters are being read
  25. into the input buffer.  That's a rare operation in a flex scanner because
  26. input is block-oriented.
  27.  
  28. > The other possibility is to use start states to build the string
  29. > yourself:
  30.  
  31. Hear hear!  This is in general a much better approach, as it also provides
  32. a natural way to deal with escape sequences and continued strings.
  33.  
  34.         Vern
  35.  
  36.     Vern Paxson                vern@ee.lbl.gov
  37.     Systems Engineering                ucbvax!ee.lbl.gov!vern
  38.     Lawrence Berkeley Laboratory        (510) 486-7504
  39. -- 
  40. Send compilers articles to compilers@iecc.cambridge.ma.us or
  41. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  42.