Wireshark-bugs: [Wireshark-bugs] [Bug 9369] New: What hf types really conflict (don't allow 2 hf
| Bug ID |
9369
|
| Summary |
What hf types really conflict (don't allow 2 hf's with the same abbreviation)?
|
| Classification |
Unclassified
|
| Product |
Wireshark
|
| Version |
SVN
|
| Hardware |
All
|
| OS |
All
|
| Status |
UNCONFIRMED
|
| Severity |
Major
|
| Priority |
Low
|
| Component |
Dissection engine (libwireshark)
|
| Assignee |
bugzilla-admin@wireshark.org
|
| Reporter |
jeff.morriss.ws@gmail.com
|
| CC |
jeff.morriss.ws@gmail.com, lekensteyn@gmail.com, pascal.quantin@gmail.com
|
| Depends on |
9360
|
Build Information:
SVN
--
+++ This bug was initially created as a clone of Bug #9360 +++
Bug 9360's complaint was that a FT_UINT16 and FT_STRING could not share the
same abbreviation:
~~~
The irc.response.command field is both a 16-bit integer and string. This breaks
the filtering engine:
$ dftest 'irc.response.command_parameter and not irc.response.command ==
"PONG"'
Filter: "irc.response.command_parameter and not irc.response.command == "PONG""
dftest: "PONG" cannot be converted to Unsigned integer, 2 bytes.
tshark lists only one field, of type string:
$ tshark -G fields | grep -F irc.response.command -w
F Command irc.response.command FT_STRING irc 0x0
Response command
[...]
It looks like that behavior is only valid for numeric types, not different
types such as strings and numbers?
~~~
But I also had experience that said that an int-type and a string did not
conflict, at least if the int-type had a value_string which allows the DF code
to try to convert the string back to an int. The comments I had in checkAPIs
also indicated the int-types were also compatible with booleans.
There's probably some more research to be done here.
You are receiving this mail because:
- You are watching all bug changes.
