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)
^~~~~~~~~
The strategy here is to delay resolving literals to values until
we have looked at the entire argument list.
Also we will try to commute the relation in a comparison if
we do not have a type for the return value of the function,
like any other constant.
Before:
Filter: max(1,_ws.ftypes.int8) == 1
dftest: Argument '1' is not valid for max()
max(1,_ws.ftypes.int8) == 1
^
After:
Filter: max(1,_ws.ftypes.int8) == 1
Syntax tree:
0 TEST_ANY_EQ:
1 FUNCTION(max#2):
2 FVALUE(1 <FT_INT8>)
2 FIELD(_ws.ftypes.int8 <FT_INT8>)
1 FVALUE(1 <FT_INT8>)
Instructions:
00000 STACK_PUSH 1 <FT_INT8>
00001 READ_TREE _ws.ftypes.int8 <FT_INT8> -> reg#1
00002 IF_FALSE_GOTO 3
00003 STACK_PUSH reg#1
00004 CALL_FUNCTION max(reg#1, 1 <FT_INT8>) -> reg#0
00005 STACK_POP 2
00006 IF_FALSE_GOTO 8
00007 ANY_EQ reg#0 == 1 <FT_INT8>
00008 RETURN
Filter: max(1,_ws.ftypes.int8) == 1
** (dftest:64938) 01:43:25.950180 [DFilter ERROR] epan/dfilter/sttype-field.c:117 -- sttype_field_ftenum(): Magic num is 0x5cf30031, but should be 0xfc2002cf
Similar to commit dbb9fe2a37, proto_item_fill_display_label
now uses address_to_display for FT_IPv4, FT_IPv6, and FT_FCWWN,
the other three address types that double as field types and which
have optional name resolution.
Add these to the list of types that, if present in a custom column,
has the GUI enable the checkbox to switch between "resolved" (names)
and not (values).
This allows adding custom columns with these field types with both
resolved and non resolved text. Note that the appropriate Name
Resolution preference settings must be enabled for the type as well.
Comparison relations should be allowed to commute but they can not
because we need type information to resolve literals to fvalues. For
that reason an expression like "1 == some.field" is invalid. Solve
that by commuting the relation if the first try did not succeed in
assigning a type to the LHS.
After the second try give up, that means we have a relation with
constants on both sides and that is not semantically valid.
Other relations like "matches" and "contains" are not symmetric and
should not commute anyway.
Before:
Filter: _ws.ftypes.int32 == 10
Syntax tree:
0 TEST_ANY_EQ:
1 FIELD(_ws.ftypes.int32 <FT_INT32>)
1 FVALUE(10 <FT_INT32>)
Instructions:
00000 READ_TREE _ws.ftypes.int32 <FT_INT32> -> reg#0
00001 IF_FALSE_GOTO 3
00002 ANY_EQ reg#0 == 10 <FT_INT32>
00003 RETURN
Filter: 10 == _ws.ftypes.int32
dftest: Left side of "==" expression must be a field or function, not 10.
10 == _ws.ftypes.int32
^~
After:
Filter: _ws.ftypes.int32 == 10
Syntax tree:
0 TEST_ANY_EQ:
1 FIELD(_ws.ftypes.int32 <FT_INT32>)
1 FVALUE(10 <FT_INT32>)
Instructions:
00000 READ_TREE _ws.ftypes.int32 <FT_INT32> -> reg#0
00001 IF_FALSE_GOTO 3
00002 ANY_EQ reg#0 == 10 <FT_INT32>
00003 RETURN
Filter: 10 == _ws.ftypes.int32
Syntax tree:
0 TEST_ANY_EQ:
1 FVALUE(10 <FT_INT32>)
1 FIELD(_ws.ftypes.int32 <FT_INT32>)
Instructions:
00000 READ_TREE _ws.ftypes.int32 <FT_INT32> -> reg#0
00001 IF_FALSE_GOTO 3
00002 ANY_EQ 10 <FT_INT32> == reg#0
00003 RETURN
Add all the valid bytes at once when we get to the end of the
length (or hit an invalid sequence) instead of one byte or character
at a time. This makes for a considerable speedup.
When the new-value element of the change-of-discrete choice contains context
tag zero, the tag content should be decoded as a BACnetDateTime. Closes#18747.
Use a consistent style for grammar rules.
Remove a comment that is too generic. The current code should
conform to how Python operates and does not need additional error
checking.
That reduces the number of get_progfile_dir() calls, leaving only the
calls that are done either to 1) get the pathname in order to display it
or 2) get the pathname in order to reset the library path.
That makes it easier to figure out which get_progfile_dir() calls are
made to find the directory in which (non-extcap) binaries from Wireshark
are installed and which - if any - are made to figure out the directory
in which *the currently-running executable* are stored. (Currently,
get_progfile_dir() attemps to get the former, not the latter, so
extcaps in an extcap subdirectory, for example, will get the parent
directory of that subdirectory, *not* the directory in which they weere
installed.)
João Valverde