Comment # 16
on bug 10881
from Hadriel Kaplan
I was going to fix this bug - I believe it is possible to make bitop compatible
with Lua 5.3 - but the more I think about it the more I think it's a bad idea
to support 5.3 at all.
The problem is it's effectively another language. Any script written on Lua 5.3
cannot be guaranteed to work correctly in 5.1 or 5.2, unless it's also tested
in 5.1 or 5.2.
That's technically also true for scripts written in 5.2, since that's not
identical to 5.1 either, but most of the differences were things very few
people use; the two big differences were the 'goto' and 'break'
keywords/statements and the built-in bit manipulation library, so they're easy
to know would be a problem.
5.3, on the other hand, treats numbers differently under-the-hood, with native
64-bit integer support as well. Since Wireshark's Lua deals with packet fields,
and some of them are 64-bit values, the impact this has on a script
working/not-working could be quite subtle.
Ironically the features Lua 5.3 adds to the language are quite useful for
Wireshark - including the 64-bit integer support, UTF-8 library, built-in
pack.unpack struct library functions, etc.
Unfortunately I don't know how to fix this problem without breaking something
else: if we *only* support Lua 5.3, then legacy scripts might break; if we
support compiling with *any* version, but the binary distributions are compiled
with Lua 5.2, then it will break scripts written on machines compiled with 5.3;
if we support compiling with *any* version, but the binary distributions are
compiled with Lua 5.3, then it will potentially break scripts written on
machines compiled with 5.1/5.2.
On the other hand, maybe Wireshark v2.0 is the right time to do this kind of
thing?
This problem is a lot like Python 2.x vs. 3.0. :(
You are receiving this mail because:
- You are watching all bug changes.