Related articles |
---|
Getting rid of backups in flex. robertminsk@yahoo.com (2002-01-17) |
Re: Getting rid of backups in flex. esmond.pitt@bigpond.com (Esmond Pitt) (2002-01-18) |
Re: Getting rid of backups in flex. casse@netcourrier.com (=?ISO-8859-15?q?=22Cass=E9=.Hugues@free.fr,@free.f) (2002-02-06) |
Re: Getting rid of backups in flex. dube@dino04.iro.umontreal.ca (Danny Dube) (2002-02-16) |
Re: Getting rid of backups in flex. esmond.pitt@bigpond.com (Esmond Pitt) (2002-02-28) |
Re: Getting rid of backups in flex. clint@0lsen.net (2002-03-17) |
Re: Getting rid of backups in flex. fjh@cs.mu.OZ.AU (2002-03-19) |
From: | clint@0lsen.net (Clint Olsen) |
Newsgroups: | comp.compilers |
Date: | 17 Mar 2002 22:39:19 -0500 |
Organization: | Compilers Central |
References: | 02-01-070 02-02-017 02-02-041 02-02-063 |
Keywords: | lex, comment |
Posted-Date: | 17 Mar 2002 22:39:19 EST |
In comp.compilers, you wrote:
>
> Apart from keeping the size of the state machine down, you get the
> benefit of the parser's error-recovery if any, rather than just lamely
> printing out 'illegal character %c'.
This presumes that your parser allows you to return arbitrary
"integers" back to the parser. How do you ensure that yytext[0]
doesn't collide with an already defined token in your token
definitions file? Parser generators like bison will deal with this
fine, but others will not.
-Clint
[Every version of yacc that I've seen starts its token numbers at 256
or 257 so they won't collide with character codes. -John]
Return to the
comp.compilers page.
Search the
comp.compilers archives again.