Comment # 33
on bug 9323
from Jeff Morriss
(In reply to comment #32)
> Tried another fix in r52979. This one should be safer/saner/more acceptable.
>
> In short:
> - proto_tree_add_string_* do require the string passed in to be
> null-terminated, because its contents have no relation to the length passed
> in (if it is generated, for example)
> - in this case it was the formatting that seemed necessary, as the string
> came directly from a tvb_get_ptr, so I just converted to a
> proto_tree_add_item and a proto_tree_set_text
>
> As far as I can tell nothing here actually needs backporting, so if there
> are no problems with the current patch this can be closed.
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?
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).
(I'm not saying these should be addressed via this bug.)
You are receiving this mail because:
- You are watching all bug changes.
