[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: LPEG 0.12 bug?
- From: Solra Bizna <solra@...>
- Date: Fri, 4 Jul 2014 11:50:16 -0600
I'm not sure this is the right place to send this, or even that it's a
bug in LPEG and not in my understanding of LPEG. I've got a simplified
test case that reproduces an (apparent) bug I encountered while using
LPEG to write a Base64-like decoder.
-- begin code
local lpeg = require "lpeg"
local P,V,R,C,Cc = lpeg.P,lpeg.V,lpeg.R,lpeg.C,lpeg.Cc
local AB_to_numbers_map = {["A"]=0,["B"]=1}
local function do_something(...)
print(...)
local arg = {...}
if #arg < 2 then
error("Shouldn't we have at least two captures?")
end
return AB_to_numbers_map[arg[1]] * 2 + AB_to_numbers_map[arg[2]]
end
local dummied_pattern = P{
"dummied_pattern";
dummied_pattern = (V"capture_A_or_B" * V"capture_A_or_B"
* Cc("dummy capture")) / do_something;
capture_A_or_B = C(R"AB");
}
local broken_pattern = P{
"broken_pattern";
broken_pattern = (V"capture_A_or_B" * V"capture_A_or_B")
/ do_something;
capture_A_or_B = C(R"AB");
}
-- Works, but has an extra dummy capture
dummied_pattern:match("AA")
-- Remove the dummy capture and suddenly the two capture_A_or_B matches
-- don't get to keep their captures
broken_pattern:match("AA")
-- end code
Expected output:
A A dummy capture
A A
Actual output:
A A dummy capture
AA
(followed by an error)
My actual program performs the digit-to-value mapping in its
equivalent of capture_A_or_B. This test case doesn't, but still shows
the (apparent) bug whether or not it's modified to do so.
As in this test case, I was able to get my by decoder working by
adding a dummy capture, but it doesn't seem like it should be
necessary. I could be wrong... if I am, where's the flaw in my
understanding?