lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


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?