When procssing BATCH statements, Wireshark did not properly handled keys with length < 0 , which actually means that no value
is sent on the wire..
This fixes it (and as a results, parses properly some result packets it failed to parse properly before).
Signed-off-by: Yaniv Kaul <yaniv.kaul@scylladb.com>
When procssing results, Wireshark did not properly handled keys with length -1, which actually means NULL.
This fixes it (and as a results, parses properly some result packets it failed to parse properly before).
Signed-off-by: Yaniv Kaul <yaniv.kaul@scylladb.com>
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>
Remove some unused historical files.
Aggressively disable warnings to keep the lemon source
pristine and avoid the maintenance burden for lemon itself.
Lemon has its own lax policy for warnings that doesn't match our
own and they won't accept external patches to remove the
warnings, so just ignore them. Lemon is just executed to generate
code for the Wireshark build and the minor code issues it has
have no influence at runtime.
For lemon generated code we selectively disable some linting
warnings.
Remove patches for lemon and lempar, they are no longer required
with these changes to silence warnings.
Constant logical expressions are tautologies and almost certainly
user error. Reject them as invalid.
Most of them were already rejected with insufficient type information
but some corner cases were still valid.
Before:
Filter: ${frame.number} == 3
Syntax tree:
0 TEST_ANY_EQ:
1 REFERENCE(frame.number <FT_UINT32>)
1 FVALUE(3 <FT_UINT32>)
Instructions:
00000 READ_REFERENCE ${frame.number <FT_UINT32>} -> reg#0
00001 IF_FALSE_GOTO 3
00002 ANY_EQ reg#0 == 3 <FT_UINT32>
00003 RETURN
After:
Filter: ${frame.number} == 3
dftest: Constant expression is invalid.
${frame.number} == 3
^~~~~~~~~~~~~~~~~~~~
Expressions that start with hyphen clash with command-line options.
In that case we need to pass "--" to dftest to stop processing
options.
Fix the test suite to do this. Fixes failures with dftest and
expressions like:
-2 == tcp.port
Replace the GLib option parser with getopt while at it. The GLib API
is nice but isn't a good fit for this utility and the code appears to
be inconsistent on whether "--" is left in the argv or not.
prev needs to be advanced to ptr on an invalid character even
if there aren't any bytes to copy (because we have two invalid
characters in a row.) Fixup ba7917309aFix#18769.
For ASCII encoding, most bytes are copied directly. Count consecutive
valid bytes in an accumulator and append them all at once when we
get an invalid character with the high bit set, or at the end.
This reduces the number of reallocations and allows larger, more
optimized memcpys.
Fix the following valgrind warnings:
==15172== Conditional jump or move depends on uninitialised value(s)
==15172== at 0x78B0849: unescape_and_tvbuffify_telnet_option (epan/dissectors/packet-telnet.c:1043)
==15172== Conditional jump or move depends on uninitialised value(s)
==15172== at 0x76917C8: dissect_rohc_ir_rtp_profile_dynamic (epan/dissectors/packet-rohc.c:1667)
==15172== Conditional jump or move depends on uninitialised value(s)
==15172== at 0x70DCBF1: dissect_gsm_rlcmac_downlink (epan/dissectors/packet-gsm_rlcmac.c:9770)
==15172== Conditional jump or move depends on uninitialised value(s)
==15172== at 0x6C7958E: set_mime_hdr_flags (epan/dissectors/packet-beep.c:392)
Fixes#18742
Remove unparsed lexical type and replace it with identifier
and constant. This separation is still necessary to differentiate
names (fields and function) from literals that look like names
but it has some advantages to do it at the lexical level.
The main advantage is a much cleaner and simplified grammar,
because we only have a single token type for field names, without
any loss of generality (the same name is valid for fields and
function names for example).
The CONSTANT token type is necessary to be different from literal
to provide errors for function rules.
As proto_tree_add_bits_item does not support FT_STRING header fields
dissection of non byte aligned fields containing BCD values has been
rewritten using explicit reading of the BCD values and usage of
proto_tree_add_string
Bitfields are neither allowed to be of type FT_NONE or FT_UINT_BYTES.
This commit fixes this for padding fields (being max 7 bits of zeroes,
thus FT_UINT8) and one field currently named as FT_UINT_BYTES that can
just be represented as FT_BYTES
Underline the whole expression if the error is for the function.
Before:
Filter: frame.number == abs(1, 2)
dftest: Function abs can only accept 1 arguments.
frame.number == abs(1, 2)
^~~
After:
Filter: frame.number == abs(1, 2)
dftest: Function abs can only accept 1 arguments.
frame.number == abs(1, 2)
^~~~~~~~~
Gerald Combs