Multi-octet packet access is broken

[kbara]

The property was falsified.
The pflang expression was ip[29:2]  < 231 and the packet number 16794
BPF: false, pure-lua: true

Investigation was done on ip[29:2] < 231, packet 16794; this can easily be looked at by hand, but was between git revisions, so there's no known seed to reproduce it with pflua-quickcheck.

ip[29] is < 231, but ip[29:2], a two-byte sequence, is not. Multi-octet packet accesses are parsed by pflua, but are being treated as if they were one octet; pflua-compile returns the same code.

% ./pflua-compile "ip[29] < 231"                 
local cast = require("ffi").cast
return function(P,length)
   if length < 44 then return false end
   if cast("uint16_t*", P+12)[0] ~= 8 then return false end
   return P[43] < 231
end

% ./pflua-compile "ip[29:2] < 231"
local cast = require("ffi").cast
return function(P,length)
   if length < 44 then return false end
   if cast("uint16_t*", P+12)[0] ~= 8 then return false end
   return P[43] < 231
end

---

Reproducible examples from branch testrebasedpflangprop:

Git revision 34266d3da076830ceb0672dff73adb805c37e737
The property was falsified.
The pflang expression was ip[61:4]  > 74 and the packet number 1509
BPF: true, pure-lua: false
Rerun as: pflua-quickcheck --seed=767892425 --iterations=537 properties/pflua_pipelines_match data/wingolog.pcap

Git revision 34266d3da076830ceb0672dff73adb805c37e737
The property was falsified.
The pflang expression was ip[139:4]  >= 210 and the packet number 16885
BPF: true, pure-lua: false
Rerun as: pflua-quickcheck --seed=787810658 --iterations=22 properties/pflua_pipelines_match data/wingolog.pcap

[wingo]

Wow, this is lollerterrible :) Good job catching it!

[kbara]

Most of the code was sound; it turned out to be a really tiny bug in the parser.

[kbara]

Fixed in 8efbfbc