According to Rec. ITU-T H.265 7.3.7 and 7.4.8,
when there are multiple RPS in SPS,
RPS can be predicted from previous ones.
But NumDletaPocs used to be a local variable for each RPS,
prediction will always fail.
In this change, NumDletaPocs is moved from dissect_h265_st_ref_pic_set
to dissect_h265_seq_parameter_set_rbsp, to allow access to previous RPS
data.
This change also move each RPS into a subtree.
Fix#18481
Replace several instances in which a REPLACEMENT CHARACTER was being
appended to a wmem_strbuf with a call to
wmem_strbuf_append_unichar_repl().
This reduces the number of explicit 0x00fffd or 0xfffd or... in the
code.
Effective permitted-alphabet constraints are only PER-visible for
the known-multiplier character string types (X.691 27.1). When
PER-visible, the upper bound of any code point used in the
alphabet needs to be calculated, in particular for the ALIGNED
variant, because that determines whether or not canonical order
is used (X.691 27.5.2, 27.5.4).
Note that even with the change to asn2wrs.py none of the generated
dissectors change, because we don't have any example of ASN.1
with non-PER visible permitted alphabet constraints because of
using them on non known-multiplier character string types
(like UTF8String).
There's some various edge cases that we still don't handle, but
nothing that any of the ASN.1 modules in the repository use.
(Permitted-alphabet constraints using characters outside the
ASCII range, possibly with "CharacterStringList", "Quadruple",
or "Tuple" notation, permitted-alphabet constraints that are
extensible and thus not PER-visible, etc.)
Also fix a fencepost error with the length of the octets to highlight.
Fix#18468
Instead of trying to rewrite the validation of UTF-8 for the nth
time first extract a validated string from the parser with
tvb_get_string_enc() and then do the post-processing on that
(unescape, etc.).
I noticed while implementing the equivalent for 802.11be that the number
of bits for phi and psi angles was reversed. Also, fixed the spelling of
AvgSNR.
Rewrite for speed and correctness.
This implementation is more strict with invalid
first bytes (continuation bytes, invalid codepoints and
some overlong sequences).
Returns 0 instead of -1 for invalid bytes.
That will 1) install 6.4, which isn't the recommended LTS version and 2)
install headers and libraries for MinGW-w64, not for Visual Studio.
That means that if you're trying to build with Visual Studio, things
won't work.
Use UTF-8 replacement characters for characters outside the
restricted string domain. This is particularly important to
guarantee valid UTF-8 for values outside the ASCII range.
Fix#18423
It looks like there was a cut&paste error a long time ago resulting
in the wimaxasncp.message_type field being incorrectly detected as
unused and commented out. Closes#18424.
This fixes a bug in the canfdmessage64 encoding in BLF that leads to
CAN-FD frames being interpreted as Remote Frames instead of correctly
ignoring the SRR flag. Makes canfdmessage encoding more robust as well.
RFC 1001 says that scope IDs "meet the restricted character set
of the domain system and has a leading period." Convert them from
ASCII (plus possible garbage fuzzed characters) to UTF-8. Also
check for truncation when appending them to the NetBIOS name.
Fix#18412
This change adds computed values for reports, sequence analysis between
segments, conversation and endpoint taps, and a new statistics menu
and dialog.
In SMB, display_unicode_string is used to handle null terminated
UTF-16LE strings. Do that with the normal API, instead of just
taking every other byte (which works for ASCII and nothing else.)
Do the same fix for the DirectPlay dissector, which borrowed the
code from SMB
Fix#18467.
Add a convenience function to truncate a UTF-8 string to no more
than certain length, while ensuring that the string ends with
a complete character instead of a partial sequence (by truncating
up to 3 additional bytes as necessary.)
The common use case is when a valid UTF-8 string is copied into
a buffer via snprintf, strlcpy, or strlcat and truncated, to fix
up the end of the string and keep the string valid.
The buffer holding the string must be large enough, and the string
must be valid up to the point of truncation (aside from the possible
partial sequence at the end). For speed, the function does not check
those conditions.
Ping #18412.
MS-DOS Date and MS-DOS Time are packed 16-bit values
(https://learn.microsoft.com/en-us/windows/win32/sysinfo/ms-dos-date-and-time)
and when combined they make a 32-bit value.
In the original minizip that comes with zlib, the combined dosDate
parameter is a uLong, which is 64 bits on LP64 platforms. In minizip-ng,
it is a uint32_t.
At one point, minizip-ng renamed the dosDate struct member of
zip_fileinfo to dos_date, but more recent versions changed it back
to dosDate for compatibility, except the size remains different,
so our compatibility check can't distinguish the size.
clang (and possibly other compilers) complain about shortening a 64 bit
unsigned long to a uint32_t so make the return value from our
qDateToDosDate a uint32_t as it should be to avoid warnings on
distributions with minizip-ng
Also the maximum year value that can be stored in the format is
127, since it occupies bits 9-15 of the MS-DOS Date. (There was
probably some confusion since the maximum year is 2107, but its
offset from 1980, not 1900.)
All other functions are declared with two lines:
WS_DLL_PUBLIC <type>
<function_name(<args>);
Declare wtap_block_foreach_option() that way, too, for consistency.