Problem with lexical analysis of pl/sql tokens

Hey guys,




I'm having a heck of a time trying to parse pl/sql string constants (in
lex). The problem , for me at least, lies in how quotes are escaped.




for example, a plsql string constant looks like so
'this is a plsql string constant'


enclosed with apostrophes


to include apostrophes in strings, you duplicate the apostrophe, as in


'this is cheryl''s book'


The Way Ive Tackled It Is By Matching Parts Then Joining With yymore()


so when i get a match first up, yytext will be
'this is cheryl'
then: 's book'


with yymore() i am able to keep a temporary buffer which builds upon
the previous.




The way i handle returning the token is to, when hitting something
other than a string constant, to return the string constant token, call
yyless(0), sparking the token that matched after the string constant to
be matched again - i am then able to return THAT token


thats all well and good when we have something like 'hello world' ;
(assuming the ; signifies an end statement token)


note the whitespace between the string constant and the end statement
token.
as i was saying, its all well and good when i have the whitespace in
there because it clears yytext() and then reparse the last token (the
end statement token) , which as i mentioned before will be the token
that handles both the string constant token and itself.


But when there is no whitespace between the constant and the end
statement token, it matches fine, but yytext contains both the string
constant and the end statement token , but my yyless call doesnt chuck
yytext out.


Im sorry if this is a convoluted way of explaining, i can try to
clarify if need be.
Is there anyone that's run into a similar situation, or can feel my
pain? maybe im going about this the whole wrong way? any
ideas/suggestions would of course be appreciated


Thanks group
Jason
[Yuck. Why not match a string directly with something like this:


\'([^']|\'\')*\'


-John]

Return to the comp.compilers page.
Search the comp.compilers archives again.