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.
___________________________________________________________________________
Sent via: Wireshark-dev mailing list <[email protected]>
Archives: http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:[email protected]?subject=unsubscribe
