Wireshark-dev: Re: [Wireshark-dev] Current Lua test failures on the buildbot
From: João Valverde <[email protected]>
Date: Sun, 7 Aug 2016 04:02:39 +0100

On 08/07/2016 03:47 AM, Guy Harris wrote:
Tested on an up-to-date Ubuntu 15.10 system; the test fails.  The TShark build information is:

	TShark (Wireshark) 2.3.0 (v2.3.0rc0-230-ge32890a from master)

	Copyright 1998-2016 Gerald Combs <[email protected]> and contributors.
	License GPLv2+: GNU GPL version 2 or later <http://www.gnu.org/licenses/old-licenses/gpl-2.0.html>
	This is free software; see the source for copying conditions. There is NO
	warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

	Compiled (64-bit) with libpcap, with POSIX capabilities (Linux), with libnl 3,
	with GLib 2.46.2, with zlib 1.2.8, with SMI 0.4.8, with c-ares 1.10.0, with Lua
	5.2, with GnuTLS 3.3.15, with Gcrypt 1.6.3, with MIT Kerberos, with GeoIP.

	Running on Linux 4.2.0-42-generic, with locale en_US.UTF-8, with libpcap version
	1.7.4, with GnuTLS 3.3.15, with Gcrypt 1.6.3, with zlib 1.2.8.
	Intel(R) Core(TM) i7-4980HQ CPU @ 2.80GHz (with SSE4.2)

	Built using gcc 5.2.1 20151010.

It also fails on an Ubuntu 14.10 system; the TShark build information is:

	TShark (Wireshark) 2.3.0 (v2.3.0rc0-230-ge32890a from master)

	Copyright 1998-2016 Gerald Combs <[email protected]> and contributors.
	License GPLv2+: GNU GPL version 2 or later <http://www.gnu.org/licenses/old-licenses/gpl-2.0.html>
	This is free software; see the source for copying conditions. There is NO
	warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

	Compiled (64-bit) with libpcap, without POSIX capabilities, with libnl 3, with
	GLib 2.42.1, with zlib 1.2.8, without SMI, without c-ares, with Lua 5.2, without
	GnuTLS, without Gcrypt, without Kerberos, without GeoIP.

	Running on Linux 3.16.0-44-generic, with locale en_US.UTF-8, with libpcap
	version 1.6.2, with zlib 1.2.8.
	Intel(R) Core(TM) i7-4980HQ CPU @ 2.80GHz (with SSE4.2)

	Built using gcc 4.9.1.

For what it's worth, the tests in question seem to be working on a "string" that's a byte array with byte values from 0 to 255; that's not a valid UTF-8 string, so if the processing that's failing is assuming a UTF-8 string, its behavior isn't guaranteed not to change from, say, GLib release to GLib release.
To be honest having our own GLib lrexlib bindings is a horrible idea 
(even more so for a possibly useful feature).
Brilliant piece of code but it should be merged upstream, not maintained 
in the Wireshark tree with a bus factor of 1.