On Thu, 2003-01-23 at 04:45, Tim Potter wrote:
> While mucking around with the Match -> Selected function yesterday
> (what a great feature - I can't believe I had never used it before!)
> I found a bit of a problem.
>
> Specifically, if you are trying to match a FT_BYTES field that is
> longer than 20 characters, the filter string generated by ethereal
> is incorrect. It looks like the gtk label string is used to generate
> the filter text and the ellipsis is rightly detected as a syntax error.
>
> Anyone have any good ideas on how to fix it? My gtk programming is
> very rusty but I remember some sort of data field attached to all
> gtk widgets which could be used to store the full field representation.
>
Hmm, looks like the code in proto.c knew about that possibility but did
nothing about it:
case FT_BYTES:
case FT_UINT_BYTES:
/*
* 4 bytes for " == ".
* 3 bytes for each byte of the byte string, as
* "NN:", minus 1 byte as there's no trailing ":".
* 1 byte for the trailing '\0'.
*
* XXX - what are the other 2 bytes for?
*/
dfilter_len = fvalue_length(finfo->value)*3 - 1;
dfilter_len += abbrev_len + 4 + 2 + 1;
buf = g_malloc0(dfilter_len);
snprintf(buf, dfilter_len, "%s == %s",
hfinfo->abbrev,
/* XXX - bytes_to_str_punct() will truncate long strings with '...' */
bytes_to_str_punct(fvalue_get(finfo->value),
fvalue_length(finfo->value),':'));
This code needs to call a new function (or a modified
bytes_to_str_punct) that will covert the entire byte array to a string.
Actually, the snippets of code in proto_alloc_dfilter_string should all
be moved into the type definitions in the ftypes directory, since the
type system is somewhat object-oriented. There, the FT_BYTES type could
provide a "string representation" "method".
--gilbert
