The comments claim that UAT_AFFECTS_FIELDS also triggers a redissection,
but it does not. Fortunately, all UATs whose flags have UAT_AFFECTS_FIELDS
also have UAT_AFFECTS_DISSECTION.
dfilter macro expressions are a rare case of a UAT that should trigger
FieldsChanged but not PacketDissectionChanged. (It's slightly
unnecessary to invalidate the custom columns, but perhaps in the
future macros will be possible in custom columns.)
So resolve things by changing the comments to reflect current reality
and making the dfilter macro UAT flags UAT_AFFECTS_FIELDS.
This prevents a crash when removing a dfilter macro thus invalidating
the current filter, and then opening a file (including reloading the
current one.)
Fix#13753
When rescanning or retapping, if there is a currently selected packet
in the GUI, load any field references in any filters for any tap
listeners.
Note that Lua plugins can register some filtering tap listeners later
after we reset the dissection tree, but those are for field extraction
in the new tree and can't contain field references.
Fix#18912
Because existing code is dependant on the behavior that a null/empty
filter is a sort of valid input (presumably to avoid having to check
for that condition explicitly) add back that behavior to avoid a lot
of potential hidden cascading failures.
Fail compilation if error pointer is set. Remove other redundant
failure flags.
Remove lemon %parse_failure block. This should be unnecessary.
I think this is only useful if we are doing error recovery,
which we aren't.
Exposing the fvalue_t implementation is exposing internal
details of the implementation. Fix that by making the fvalue_t
internal to the ftypes implementation and using setters/getters
where necessary.
Add option to dump runtime data structures in a compiled display
filter. As the comment notes:
/* NOTE: References are loaded during runtime and dftest only does compilation.
* Unless some static reference data is hard-coded at compile time during
* development the --refs option to dftest is useless because it will just
* print empty reference vectors. */
Add functions to test if a compiled dfilter considers an hfid
or a protocol id interesting. Use those to define functions to
test if any enabled color filter considers an hfid or a protocol
interesting.
Develpment headers are a sizeable part of the binary installation
and most users won't ever require them. It's recommended to package
them separately in a devel package or SDK.
Create a CMake installation component for development headers
and add the EXCLUDE_FROM_ALL property.
Headers can be installed using the invocation:
cmake --install <dir> --component Development
Originally WS_DISABLE_DEBUG was chosen to be
similar to G_DISABLE_ASSERT and NDEBUG.
However generator expressions are essential for modern CMake
but the syntax is weird and having to use negations makes it
ten-fold worse.
Remove the negation. Instead of changing the CMake variable
reverse the macro definition for WS_DISABLE_DEBUG.
The $<CONFIG:cgs> generator expression with multiple config arguments
requires CMake >= 3.19 so we can't use that yet for a further
syntactical simplification.
- ws_assert does not work, because _ASSERT_ENABLED is false and gets optimized
- add _U_ to unused variables because of compile flag /W3
- local variables need suppression of warning 4189
This omits the flex debug code in the binary if the build type is
RelMinSize or Release.
It replaces the "%option debug" stanza with the -d command line
option, to be able to configure the flex behaviour.
Cleanup flex code. Optimize some patterns to avoid lookups
for field matches for values that are not legal field names.
Improve warning and add some comments.
No one is using this so I'd like to explore other
options first to handle constants in arithmetic
expressions that lack type information.
Reverts 3ddb017a88.
Make dfilter byte representation always use ':' for consistency.
Make 1 byte be represented as "XX:" with the colon suffix to
make it nonambiguous that is is a byte and not other type,
like a protocol.
The difference is can be seen in the following programs. In the
before representation it is not obvious at all that the second
"fc" value is a literal bytes value and not the value of the
protocol "fc", although it can be inferred from the lack of
a READ_TREE instruction. In the After we know that "fc:" must
be bytes and not a protocol.
Note that a leading colon is a syntactical expedient to say
"this value with any type is a literal value and not a protocol
field." A terminating colon is just a part of the dfilter
literal bytes syntax.
Before:
Filter: fc == :fc
Syntax tree:
0 TEST_ANY_EQ:
1 FIELD(fc <FT_PROTOCOL>)
1 FVALUE(fc <FT_PROTOCOL>)
Instructions:
00000 READ_TREE fc <FT_PROTOCOL> -> reg#0
00001 IF_FALSE_GOTO 3
00002 ANY_EQ reg#0 == fc <FT_PROTOCOL>
After:
Filter: fc == :fc
Syntax tree:
0 TEST_ANY_EQ:
1 FIELD(fc <FT_PROTOCOL>)
1 FVALUE(fc: <FT_PROTOCOL>)
Instructions:
00000 READ_TREE fc <FT_PROTOCOL> -> reg#0
00001 IF_FALSE_GOTO 3
00002 ANY_EQ reg#0 == fc: <FT_PROTOCOL>
João Valverde