Related articles |
---|
a token scanner DFA for indirection operator * ? rgesell@mb.sympatico.ca (RonG) (2004-03-26) |
Re: a token scanner DFA for indirection operator * ? alexc@std.com (Alex Colvin) (2004-04-03) |
Re: a token scanner DFA for indirection operator * ? vbdis@aol.com (2004-04-03) |
Re: a token scanner DFA for indirection operator * ? mailbox@dmitry-kazakov.de (Dmitry A. Kazakov) (2004-04-03) |
Re: a token scanner DFA for indirection operator * ? casse@netcourrier.fr (=?ISO-8859-1?Q?Cass=E9_Hugues?=) (2004-04-15) |
From: | =?ISO-8859-1?Q?Cass=E9_Hugues?= <casse@netcourrier.fr> |
Newsgroups: | comp.compilers |
Date: | 15 Apr 2004 12:29:58 -0400 |
Organization: | A Customer of Tele2 |
References: | 04-03-102 04-04-006 |
Keywords: | lex |
Posted-Date: | 15 Apr 2004 12:29:58 EDT |
Yes, there is a way. Please look at my own C front-end in OCAML
(http://casse.hugues.free.fr/projects/frontc.html). The "*" may be used
prefixed or infixed in C expression: not a problem for LR(1) parser. In
type definition, the "context" is very different and no problem arises.
Issues come from the declaration types using "typedef" names. In case
of blocks "{" ... "}", knowledge of symbol kind is required in order to
separate declaring part from statement part.
Hugues Cassé.
Alex Colvin wrote:
>>I'm trying to write a token scanner for C, and I'm wondering if there is a
>>detrministic finite automata (DFA) or state machine for the '*'
>>indirection operator(IOP), or if differentiation between the multiply
>>operator and the IOP is better left to the parser. Right now my scanner
>
>
> This is usually left to the parser.
> you have to distinguish
> (int)*ptr
> (width)*height
> which requires knowing that "int" is a type (or typedef) in the current
> scope.
Return to the
comp.compilers page.
Search the
comp.compilers archives again.