Bug ID |
9725
|
Summary |
Lua: ProtoField.new() is buggy
|
Classification |
Unclassified
|
Product |
Wireshark
|
Version |
1.10.5
|
Hardware |
x86
|
OS |
Mac OS X 10.4
|
Status |
UNCONFIRMED
|
Severity |
Normal
|
Priority |
Low
|
Component |
Dissection engine (libwireshark)
|
Assignee |
[email protected]
|
Reporter |
[email protected]
|
Build Information:
TShark 1.10.5 (SVNRev 54262 from /trunk-1.10)
Copyright 1998-2013 Gerald Combs <[email protected]> and contributors.
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 GLib 2.36.0, with libpcap, with libz 1.2.3, without
POSIX
capabilities, without libnl, with SMI 0.4.8, without c-ares, without ADNS, with
Lua 5.1, without Python, with GnuTLS 2.12.19, with Gcrypt 1.5.0, with MIT
Kerberos, with GeoIP.
Running on Mac OS X 10.9.1, build 13B42 (Darwin 13.0.0), with locale
en_US.UTF-8, with libpcap version 1.3.0 - Apple version 41, with libz 1.2.5.
Intel(R) Core(TM) i7 CPU M 620 @ 2.67GHz
Built using llvm-gcc 4.2.1 (Based on Apple Inc. build 5658) (LLVM build
2336.9.00).
--
Using ProtoField.new() is dicey. Many of the optional arguments don't properly
check the lua stack - they call lua_isnil() for their index number, instead of
lua_gettop() to see the stack size. lua_isnil() may return false in such
cases.
For example, try this simple one-line lua script:
local trasaction_id = ProtoField.new("Trans ID", "trans_id", "ftypes.UINT16")
You will get this error:
bad argument #4 to 'new' (must be a table)
...because it thinks there's an optional 4th argument (VALUESTRING).
I'm not sure this is worth fixing in 1.10.5, since few people use
ProtoField.new() apparently - they just use the direct ProtoField type
accessors. And since this function changed a lot in 1.11 it might be worth
just fixing there.
I'll submit a fix to gerrit for 1.11, since that's all I have access to.
You are receiving this mail because:
- You are watching all bug changes.