We use a common idiom ( https://stackoverflow.com/a/39606065https://gist.github.com/hynekcer/1b0a260ef72dae05fe9611904d7b9675 )
for getting the results of our unittest.TestCases in the tearDown
method. This method accesses a private property, and that private
property was removed in Python 3.11
The StackOverflow answer has been updated with a new approach for
Python 3.11, which also uses a private property. This fixes things
for CTest (and the test target when building), but it still doesn't
work when using pytest's unittest support.
Ping #18740
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.
We want at least one letter. Because protocol names can contain
dots and hyphens testing for !isdigit is not enough to make it
dissimilar to decimal numeric expressions.
- Show which options are referenced by entries in entry overview.
- Show IPv6 address in option overview too (before IPv4 only).
- Only register ports of endpoint referenced by SOME/IP services.
Endpoint Options referenced by Service 0xfffe (non SOME/IP) are not
automatically registered to be SOME/IP anymore [improvement].
Remove MINIMIZE_STRING_COPYING define because the code does not even
compile anymore. Do not cache strings when ensuring rows are colorized
to avoid thrashing cache. Store column data only for last 500 accessed
records to ensure there is upper bound for the cache size.
Fixes#18741
Calculating ipei_digits happened using signed int arithmetic due to type
promotion rules. Explicitely casting the static number to guint64
ensures usage of unsigned 64bit arithmetics.
The extended location information type field is a four bit value. This
was handled correctly while displaying, but not by interpreting the
value. Hence the according MASK and SHIFT values have been updated.
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>
Developer Alexander