| Bug ID |
9790
|
| Summary |
Lua: wslua allows duplicate field registration
|
| Classification |
Unclassified
|
| Product |
Wireshark
|
| Version |
1.11.x (Experimental)
|
| Hardware |
x86
|
| OS |
Mac OS X 10.9
|
| Status |
UNCONFIRMED
|
| Severity |
Minor
|
| Priority |
Low
|
| Component |
Dissection engine (libwireshark)
|
| Assignee |
[email protected]
|
| Reporter |
[email protected]
|
Build Information:
TShark 1.10.5 (SVN Rev Unknown from unknown)
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.38.2, with libpcap, with libz 1.2.8, without
POSIX
capabilities, without libnl, with SMI 0.4.8, without c-ares, with ADNS, with
Lua
5.2, without Python, with GnuTLS 3.1.10, with Gcrypt 1.5.3, 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.5.3, with libz 1.2.8.
Intel(R) Core(TM) i7 CPU M 620 @ 2.67GHz
Built using clang 4.2.1 Compatible Apple LLVM 5.0 (clang-500.2.79).
--
I'm submitting this bug to split out a separate issue discussed in bug 3513.
As discussed there, one can register more than one new ProtoFields for the same
field name - even for existing ones already in C-code.
I'm not sure it's a bug, technically. C-code can register duplicate field
abbreviations as well. See this comment in epan/proto.c:
/* We allow multiple hfinfo's to be registered under the same
* abbreviation. This was done for X.25, as, depending
* on whether it's modulo-8 or modulo-128 operation,
* some bitfield fields may be in different bits of
* a byte, and we want to be able to refer to that field
* with one name regardless of whether the packets
* are modulo-8 or modulo-128 packets. */
Wireshark's lua does correctly catch and error duplicate protocol names (i.e.,
using Proto.new()), but ProtoFields are not prevented from being duplicate with
others. It's not "normal" though, and can lead to weird scenarios. The new
field doesn't replace the old one - they're both kept and used, which can be
buggy if they're not the same basic type (i.e., both uint16 or whatever).
Should lua be stricter and prevent duplication of ProtoFields? We could do it
with an optional non-default arg to "force" such registration.
You are receiving this mail because:
- You are watching all bug changes.