Wireshark-dev: Re: [Wireshark-dev] On Copy as Filter
From: Guy Harris <guy@xxxxxxxxxxxx>
Date: Fri, 5 Jun 2009 17:26:25 -0700

On Jun 5, 2009, at 4:29 PM, didier wrote:

Le samedi 06 juin 2009 à 00:26 +0200, Sake Blok a écrit :
On Fri, Jun 05, 2009 at 11:55:02PM +0200, didier wrote:
Le dimanche 31 mai 2009 à 11:56 +0200, Sake Blok a écrit :
Hi Jaap (& list),

As the "father" of the "copy as filter" functionality, I would vote for it to be present all the time in the packet details pane (where I use it most). Keeping track of all possible filters for the packet list pane seems like an overkill to me and could be made optional to save memory. Or it should be implemented in a way where it will dynamically be generated. For 1.2.0 I would suggest to just revert the implemented memory-consuming patch and disable the functionality in the packet-list. Then we can decide later to make it either optional of write code that dynamically generate the filter
string on use (if that is at all possible).

Anyone remember why it was changed from dynamically generate?
The SVN log msg doesn't make sense to me.

Presumably the log is

r27396 | jake | 2009-02-08 23:10:46 -0800 (Sun, 08 Feb 2009) | 7 lines

  Make "Copy as Filter" on the packet list actually work.
Up till now every packet in the packet list got a copy of the pointer to the filter expressions for the last packets' columns. Hence any 'Copy as Filter" on a column got the expression of the last packet in the packet list. Instead every packet needs to get a pointer to the filter expressions for its own columns. This requires making a copy of the filter expressions themselves.

Since this is a bug in 1.0 as well the GLIB1 code is provided for backporting, which can later be dropped from the development tree.

IIRC, the filter strings were not generated dynamically, they were
generated while building the packet-list, resulting in having the
filters for the last row to be the filters for all rows. But my memory
might not be totally accurate ;-)
It was generated, cf svn  24511 but:
1- didn't work with col_custom
2- use ep_alloc, a bit dangerous?

attached a modified version which work for me.

This would presumably be combined with a complete removal of the col_expr field from the frame_data structure, right?

Actually, get_filter_from_packet_list_row_and_column() (I renamed the function from get_text_from_packet_list() to indicate in more detail what it does - it doesn't fetch arbitrary text, it fetches a filter expression) is called only by match_selected_plist_cb(), which passes it to match_selected_cb_do(), which always uses it to make a copy, so if we just had get_filter_from_packet_list_row_and_column() create the string with g_strdup_printf() and changed match_selected_plist_cb() to

	char *filter_text;

	filter_text = get_filter_from_packet_list_row_and_column(data);
	match_selected_cb_do(data, action, filter_text);
	g_free(filter_text);

(or incorporated get_filter_from_packet_list_row_and_column() into match_selected_plist_cb()), that would mean that we wouldn't have to worry about ephemeral vs. per-session strings.