Wireshark-bugs: [Wireshark-bugs] [Bug 9323] Buildbot crash output: fuzz-2013-10-25-12569.pcap
Comment # 34
on bug 9323
from Evan Huus
(In reply to comment #33)
> Don't we still have the issue that we claim the string doesn't have to be
> NULL terminated but it does? Should we just give up on FT_STRING?
I don't think we are claiming that, I think the documentation is just really
confusing and poorly worded.
The type FT_STRING represents a string in the packet that is not necessarily
NULL-terminated. The type FT_STRINGZ represents a string in the packet that
must be NULL-terminated.
However, the string argument to proto_tree_add_string (and related ones) has
*no relation* to those definitions. In fact the hf var passed in can be of
either type. The string argument to those functions also does not necessarily
have any relation to the packet, for example I could do something like
ti = proto_tree_add_string(tree, hf_username, tvb, offset, 0, "MyUsername");
PROTO_ITEM_SET_GENERATED(ti);
Where MyUsername is some string I have stored in a conversation structure but I
don't want to highlight any bytes in the packet.
Therefore while we never explicitly say the string must be null-terminated, the
assumption is that it must be (and as far as I know all other callers assume it
must be as well).
> Another thought I had was that the only reason the HTTP dissector is
> formatting the string here is to clean it up. Which we arguably should be
> doing for the values, too, before the user can use them in "Apply as Filter"
> or whatever (as the comments in tvb_get_string_enc() suggest).
This is a whole can of worms related to the email I sent to -dev on string
handling. Continue this discussion there?
You are receiving this mail because:
- You are watching all bug changes.
