tvb_new_subset -> tvb_new_subset_remaining it appears that's what the intention is.
Change-Id: I2334bbf3f10475b3c22391392fc8b6864454de2d
Reviewed-on: https://code.wireshark.org/review/1999
Reviewed-by: Pascal Quantin <pascal.quantin@gmail.com>
wmem_packet_scope() cannot be used outside of a packet treatment
Change-Id: I6e545bbb51f325b366288f17358f9d2347a7d7c4
Reviewed-on: https://code.wireshark.org/review/977
Reviewed-by: Pascal Quantin <pascal.quantin@gmail.com>
Change-Id: I7489e2fb3a1f2630ca17b0a5fe1aa873992f1061
Reviewed-on: https://code.wireshark.org/review/975
Reviewed-by: Michael Mann <mmann78@netscape.net>
(Using sed : sed -i '/^ \* \$Id\$/,+1 d')
Fix manually some typo (in export_object_dicom.c and crc16-plain.c)
Change-Id: I4c1ae68d1c4afeace8cb195b53c715cf9e1227a8
Reviewed-on: https://code.wireshark.org/review/497
Reviewed-by: Anders Broman <a.broman58@gmail.com>
I'm not sold on the name or module the proto_data functions live in, but I believe the function arguments are solid and gives us the most flexibility for the future. And search/replace of a function name is easy enough to do.
The big driving force for getting this in sooner rather than later is the saved memory on ethernet packets (and IP packets soon), that used to have file_scope() proto data when all it needed was packet_scope() data (technically packet_info->pool scoped), strictly for Decode As.
All dissectors that use p_add_proto_data() only for Decode As functionality have been converted to using packet_scope(). All other dissectors were converted to using file_scope() which was the original scope for "proto" data.
svn path=/trunk/; revision=53520
1. Case sensitivity differences between hf_ field name and formatted string.
2. Unnecessary whitespace between hf_ field name and colon in formatted string
There are cases where the hf_ field name doesn't quite match the proto_tree_add_uint_format, but it's close enough that one of them should be "right", I'm just not sure which is, I just know the string in proto_tree_add_uint_format is the one displayed.
svn path=/trunk/; revision=52098
The script didn't catch as many as I would have liked, but it's a start.
The most common (ab)use of proto_tree_add_uint_format was for appending strings to CRC/checksum values to note good or bad CRC/checksum.
svn path=/trunk/; revision=52045
Cast away some implicit 64-bit-to-32-bit conversion errors due to use of
sizeof.
Cast away some implicit 64-bit-to-32-bit conversion errors due to use of
strtol() and strtoul().
Change some data types to avoid those implicit conversion warnings.
When assigning a constant to a float, make sure the constant isn't a
double, by appending "f" to the constant.
Constify a bunch of variables, parameters, and return values to
eliminate warnings due to strings being given const qualifiers. Cast
away those warnings in some cases where an API we don't control forces
us to do so.
Enable a bunch of additional warnings by default. Note why at least
some of the other warnings aren't enabled.
randpkt.c and text2pcap.c are used to build programs, so they don't need
to be in EXTRA_DIST.
If the user specifies --enable-warnings-as-errors, add -Werror *even if
the user specified --enable-extra-gcc-flags; assume they know what
they're doing and are willing to have the compile fail due to the extra
GCC warnings being treated as errors.
svn path=/trunk/; revision=46748
Feedback NACK PID", not just as "RTCP Transport Feedback NACK", and give
the field a name for that.
Use it in the protocol tree for the bits of the BLP field, rather than
making it a hidden field there.
Clean up the tags appended to the BLP field.
svn path=/trunk/; revision=45157
text.
Don't put empty items into the bitfield tree.
Show the BLP field as hex, as it's a bitfield.
(What should *really* happen is that it should display each 1 bit in the
usual fashion, with the ".... ...1 .... ...." display, but have that bit
be an *integral* field with the appropriate PID for the NACKed packet -
i.e., display hf_rtcp_rtpfb_nack_pid, with the value
rtcp_rtpfb_nack_pid + i + 1, and with the bitfield stuff in the
displayed representation.)
svn path=/trunk/; revision=45155
1. If there's no character encoding (ENC_ASCII, ...) specified
then use ENC_ASCII.
2. For all but FT_UINT_STRING, always use ENC_NA
(replacing any existing True/1/FALSE/0
/ENC_BIG_ENDIAN/ENC_LITTLE_ENDIAN).
svn path=/trunk/; revision=39426
Specifically: Replace FALSE|0 and TRUE|1 by ENC_BIG_ENDIAN|ENC_LITTLE_ENDIAN as
the encoding parameter for proto_tree_add_item() calls which directly reference
an item in hf[] which has a type of:
FT_BOOLEAN
FT_IPv4
FT_EUI64
FT_GUID
FT_UINT_STRING
Also: For type FT_ITv6 use ENC_NA. (This was missed in SVN #39260)
svn path=/trunk/; revision=39328
Dario Lombardo