Re: Lua 5.3

[Peter Wu <peter () lekensteyn nl>]

On Mon, Aug 08, 2016 at 09:17:35PM +0100, João Valverde wrote:
> On 08/08/2016 05:58 PM, Pascal Quantin wrote:
> > Hi João,
> >
> > 2016-08-08 18:52 GMT+02:00 João Valverde
> > <joao.valverde () tecnico ulisboa pt
> > <mailto:joao.valverde () tecnico ulisboa pt>>:
> >
> >     Is moving to Lua 5.3 something we should look into?
> >
> >     The 64 bit integer support seems really promising.
> >
> >
> > Hariel explained us that Lua 5.3 was a completely different language (a
> > bit like what you have between Python 2.X and 3.X). You can find much
> > more info (from people knowing what they are taling about - so not me
> > ;)) in bug 10881.
> >
> > Pascal.
>
>
> Thanks for that Pascal. The only sane way to approach the issue IMHO is to
> accept that this may and probably will break backward compatibility (not
> even think about supporting 5.1 or 5.2) and just consider whether that break
> is justified (hint: it is).

Why is it justified to break backwards compatibility and move from 5.2
to 5.3 without the ability to chose for 5.2? What is the killer feature
of 5.3 that makes it totally worth to possibly break older dissectors?

The disadvantage of C plugins is that it had to be recompiled for newer
versions. With a move from 5.2 to 5.3 and also removing GRegex and bitop
you make it quite likely to break Lua dissectors in some way.

I have once written a Lua library in C, interfacing with Libgcrypt for
which I studied the Lua manual. The API changes with 5.3 were not that
significant if I remember correctly (though you have to be careful with
providing a compatibility layer), but the ABI is certainly not
compatible.

In the recent proposed patches, you seem to have no issues with breaking
backwards compatibility. Have you developed Lua dissectors before?
Breaking things for the sake of "shiny, new, future" is not an
acceptable motivation, there must be something more appealing to justify
such breakage. Having 64-bit integer support, but taking away the bitop
library is a net loss without even considering the other factors.
-- 
Kind regards,
Peter Wu
https://lekensteyn.nl
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe