lpeg re.lua bug and provided fix

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

lpeg re.lua bug and provided fix

Albert Chan
= re.match("aaand", "[a]^2")
.\re.lua: attempt to perform arithmetic on local 'p' (a string value)

the fix is simple, just make sure class range ALWAYS return lpeg object

Since class complement function always run, just fix it:

< function(c, p) return c == "^" and any - p or p end
---
> function(c, p) return c == "^" and any - p or m.P(p) end

redo above
= re.match("aaand", "[a]^2")
3


Reply | Threaded
Open this post in threaded view
|

Re: lpeg re.lua bug and provided fix

Roberto Ierusalimschy
> = re.match("aaand", "[a]^2")
> .\re.lua: attempt to perform arithmetic on local 'p' (a string value)
>
> the fix is simple, just make sure class range ALWAYS return lpeg object

Thanks for the report.

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: lpeg re.lua bug and provided fix

Roberto Ierusalimschy
> > = re.match("aaand", "[a]^2")
> > .\re.lua: attempt to perform arithmetic on local 'p' (a string value)
> >
> > the fix is simple, just make sure class range ALWAYS return lpeg object
>
> Thanks for the report.
>
> -- Roberto

BTW, a cleaner fix seems to be this:

-local item = defined + Range + m.C(any)
+local item = defined + Range + m.P(any)

Then, 'item' always results in a pattern.

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: lpeg re.lua bug and provided fix

Roberto Ierusalimschy
> > > = re.match("aaand", "[a]^2")
> > > .\re.lua: attempt to perform arithmetic on local 'p' (a string value)
> > >
> > > the fix is simple, just make sure class range ALWAYS return lpeg object
> >
> > Thanks for the report.
> >
> > -- Roberto
>
> BTW, a cleaner fix seems to be this:
>
> -local item = defined + Range + m.C(any)
> +local item = defined + Range + m.P(any)
>
> Then, 'item' always results in a pattern.

Sorry...

-local item = defined + Range + m.C(any)
+local item = defined + Range + m.C(any) / m.P

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: lpeg re.lua bug and provided fix

Albert Chan
On Jan 31, 2018, at 8:40 AM, Roberto Ierusalimschy <[hidden email]> wrote:

= re.match("aaand", "[a]^2")
.\re.lua: attempt to perform arithmetic on local 'p' (a string value)

the fix is simple, just make sure class range ALWAYS return lpeg object

Thanks for the report.

-- Roberto

BTW, a cleaner fix seems to be this:

-local item = defined + Range + m.C(any)
+local item = defined + Range + m.P(any)

Then, 'item' always results in a pattern.

Sorry...

-local item = defined + Range + m.C(any)
+local item = defined + Range + m.C(any) / m.P

-- Roberto


I think my original patch in the complement functon is safer, and more efficient

We do not need every item to be lpeg object, only its built class
(item were used ONLY to build class range)

one of item choice is defined, which included user defined constants 
that may not be lpeg object. So, the bug is still there.

pat = re.compile("[%star]^10", {star = "*"})
.\re.lua: attempt to perform arithmetic on local 'p' (a string value)
Reply | Threaded
Open this post in threaded view
|

Re: lpeg re.lua bug and provided fix

Roberto Ierusalimschy
> We do not need every item to be lpeg object, only its built class
> (item were used ONLY to build class range)

I don't think this is true. All uses of 'item' demand it to be a
pattern. What happens is that other operations (e.g., '*', '-')
coerce it to a pattern when it is not one.


> one of item choice is defined, which included user defined constants
> that may not be lpeg object. So, the bug is still there.

Sure. It should be fixed, too.

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: lpeg re.lua bug and provided fix

Albert Chan

On Feb 1, 2018, at 10:59 AM, Roberto Ierusalimschy <[hidden email]> wrote:

We do not need every item to be lpeg object, only its built class
(item were used ONLY to build class range)

I don't think this is true. All uses of 'item' demand it to be a
pattern. What happens is that other operations (e.g., '*', '-')
coerce it to a pattern when it is not one.


one of item choice is defined, which included user defined constants
that may not be lpeg object. So, the bug is still there.

Sure. It should be fixed, too.

-- Roberto


local item = defined + Range + m.C(any)
+local item = (defined + Range + m.C(any)) / m.P

this should fix it.

-- Albert Chan