Make Lua function compiled via BPF return true or false

[dpino]

There's an inconsistency between the value returned in the BPF pipeline if the function is compiled directly or if it's printed as source code and later loaded. In the first case, the function returns a boolean:

local bpf_prog = bpf.compile(bytecode)
return function(P, len) return bpf_prog(P, len) ~= 0 end

In the second case, the function returns an integer. The user of this function must remember to compared the result of this function against zero.

   ::L9::
   do return 65535 end
   ::L10::
   do return 0 end
   error("end of bpf")

This creates an inconsistency while running pflua-match, as it doesn't make a difference between whether the function was compiled or was loaded from a file. For instance:

tools $ ./pflua-match --bpf v4.pcap "esp"
Matched 0/43 packets in 823662 iterations: v4.pcap (35.417466 MPPS).

tools $ ./pflua-compile --bpf-lua "esp" > esp-bpf.lua
tools $ ./pflua-match v4.pcap "esp-bpf.lua" 
Matched 43/43 packets in 767135 iterations: v4.pcap (32.986805 MPPS).

One solution is to tweak pflua-match and check whether the result returned is of type integer, and in that case compare against zero. Another solution, is to modify the returned function compiled by the BPF pipeline, so it returns true or false directly. I prefer the second solution, so it's consistent with the Lua pipeline and users don't have to remember this fact.

[wingo]

Hum, interesting. I guess we lose then the ability to compare the integer result to libpcap, and the ability to use BPF for non-packet-filtering purposes, but it's probably a good idea for the packet-filtering use case to make this change. LGTM.