When a new display filter is to be applied, don't set "cf.dfilter" or
authorguy <guy@f5534014-38df-0310-8fa8-9805f1628bb7>
Mon, 11 Oct 1999 06:39:26 +0000 (06:39 +0000)
committerguy <guy@f5534014-38df-0310-8fa8-9805f1628bb7>
Mon, 11 Oct 1999 06:39:26 +0000 (06:39 +0000)
commit8abb50f71aa923c7bc87ec4a949dce4374466135
treedfec8b639fbd755acc879b925ce7a2d2dd8e9302
parent974baaf856fcec198fa51f03581d03afe39a7f20
When a new display filter is to be applied, don't set "cf.dfilter" or
"cf.dfcode" if the new filter doesn't compile, because the filter
currently in effect will be the one that was last applied - just free up
the text of the new filter, and whatever memory was allocated for the
new filter code.

This means we allocate a new dfilter when a new filter is to be applied,
rather than recycling stuff from the old filter, as we want the old
filter code to remain around if the new filter doesn't compile.

This means that "cf.dfilter" and "cf.dfcode" will be null if there's no
filter in effect.

git-svn-id: http://anonsvn.wireshark.org/wireshark/trunk@803 f5534014-38df-0310-8fa8-9805f1628bb7
colors.c
dfilter-grammar.y
dfilter-int.h
dfilter.c
dfilter.h
file.c
file.h
gtk/file_dlg.c
gtk/main.c
summary.c