Lexer patch question

Started by Bruce Momjianabout 21 years ago4 messagespatches
Jump to latest
#1Bruce Momjian
bruce@momjian.us

I am confused why the following change Tom made to scan.l works.
Isn't that 'x' required so xqescape doesn't match '\x'?

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Attachments:

/bjm/difftext/plainDownload+2-2
#2Tom Lane
tgl@sss.pgh.pa.us
In reply to: Bruce Momjian (#1)
Re: Lexer patch question

Bruce Momjian <pgman@candle.pha.pa.us> writes:

I am confused why the following change Tom made to scan.l works.
Isn't that 'x' required so xqescape doesn't match '\x'?

*** scan.l	2 Jun 2005 01:23:08 -0000	1.123
--- scan.l	2 Jun 2005 17:45:17 -0000	1.124
***************
*** 193,199 ****
xqstart			{quote}
xqdouble		{quote}{quote}
xqinside		[^\\']+
! xqescape		[\\][^0-7x]
xqoctesc		[\\][0-7]{1,3}
xqhexesc		[\\]x[0-9A-Fa-f]{1,2}
--- 193,199 ----
xqstart			{quote}
xqdouble		{quote}{quote}
xqinside		[^\\']+
! xqescape		[\\][^0-7]
xqoctesc		[\\][0-7]{1,3}
xqhexesc		[\\]x[0-9A-Fa-f]{1,2}

No; if a match to xqhexesc is possible, the lexer will prefer that match
because it is longer. If a match to xqhexesc is not possible --- that
is, we have \x not followed by a hex digit --- then we *want* xqescape
to match. The original coding forced a backup to the <xq>. rule in this
situation, which is not how we want it to behave.

regards, tom lane

#3Bruce Momjian
bruce@momjian.us
In reply to: Tom Lane (#2)
Re: Lexer patch question

Tom Lane wrote:

Bruce Momjian <pgman@candle.pha.pa.us> writes:

I am confused why the following change Tom made to scan.l works.
Isn't that 'x' required so xqescape doesn't match '\x'?

*** scan.l	2 Jun 2005 01:23:08 -0000	1.123
--- scan.l	2 Jun 2005 17:45:17 -0000	1.124
***************
*** 193,199 ****
xqstart			{quote}
xqdouble		{quote}{quote}
xqinside		[^\\']+
! xqescape		[\\][^0-7x]
xqoctesc		[\\][0-7]{1,3}
xqhexesc		[\\]x[0-9A-Fa-f]{1,2}
--- 193,199 ----
xqstart			{quote}
xqdouble		{quote}{quote}
xqinside		[^\\']+
! xqescape		[\\][^0-7]
xqoctesc		[\\][0-7]{1,3}
xqhexesc		[\\]x[0-9A-Fa-f]{1,2}

No; if a match to xqhexesc is possible, the lexer will prefer that match
because it is longer. If a match to xqhexesc is not possible --- that
is, we have \x not followed by a hex digit --- then we *want* xqescape
to match. The original coding forced a backup to the <xq>. rule in this
situation, which is not how we want it to behave.

Oh, I didn't realize lexers would choose the longer token when given
multiple options.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073
#4Tom Lane
tgl@sss.pgh.pa.us
In reply to: Bruce Momjian (#3)
Re: Lexer patch question

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Oh, I didn't realize lexers would choose the longer token when given
multiple options.

See lines 95-100 in scan.l:

* OK, here is a short description of lex/flex rules behavior.
* The longest pattern which matches an input string is always chosen.
* For equal-length patterns, the first occurring in the rules list is chosen.
* INITIAL is the starting state, to which all non-conditional rules apply.
* Exclusive states change parsing rules while the state is active. When in
* an exclusive state, only those rules defined for that state apply.

regards, tom lane