These display bases work to replace unprintable characters so the
name is a misnomer. In addition they are the same option and this
display behaviour is not something that is configurable.
This does not affect encodings because all our internal text strings
need to be valid UTF-8 and the source encoding is specified using
ENC_*.
Remove the assertion for valid UTF-8 in proto.c because
tvb_get_*_string() must return a valid UTF-8 string, always, and we
don't need to assert that, it is expensive.
reported by check_typed_proto_items.py
packet-bluecom.c:435 proto_tree_add_item called for hf_bcp_hdr_cmd - item type is FT_UINT32 but call has len 1
packet-bluecom.c:441 proto_tree_add_item called for hf_bcp_hdr_len - item type is FT_UINT8 but call has len 2
Error:
../epan/dissectors/packet-bluecom.c:494:32: error: variable ‘segcode’ might be clobbered by ‘longjmp’ or ‘vfork’ [-Werror=clobbered]
guint cmd, flags, blocknb, segcode=0;
^
cc1: all warnings being treated as errors
Change-Id: I4534d1e95d0fb937ace34a757b7c9d36dd9e53b3
Reviewed-on: https://code.wireshark.org/review/35080
Reviewed-by: Anders Broman <a.broman58@gmail.com>
offset has to be volatile, as it's used in a loop that involves the
setjmp/longjmp-based TRY mechanism.
Instead of passing pointers to the offset to routines that dissect
headers, have the routines take the offset as an argument and return the
updated offset, to avoid having to mark said pointers as pointing to a
volatile variable.
Update comments while we're at it.
Change-Id: I3058a4e6a736c234ad7508521c9fe9da358b6096
Reviewed-on: https://code.wireshark.org/review/27109
Reviewed-by: Guy Harris <guy@alum.mit.edu>
It *looks* as if a bluecom packet has a count of blocks, and a sequence
of that number of blocks, with each one containing a block header and a
block data.
Dissect the packet in that fashion. If we get an exception (other than
"we hit the snaplen") while dissecting a block, record it and step on to
the next block.
Don't try to avoid hitting the snaplen - we *want* that to be reported,
so the user knows that the capture only includes the first part of the
packet.
Change-Id: I1b668ffea9b67d3a6ff06100b868f7d941c1f509
Reviewed-on: https://code.wireshark.org/review/27106
Petri-Dish: Guy Harris <guy@alum.mit.edu>
Tested-by: Petri Dish Buildbot
Reviewed-by: Guy Harris <guy@alum.mit.edu>
This emphasizes that there is no such thing as *the* routine to
construct a subset tvbuff; you need to choose one of
tvb_new_subset_remaining() (if you want a new tvbuff that contains
everything past a certain point in an existing tvbuff),
tvb_new_subset_length() (if you want a subset that contains everything
past a certain point, for some number of bytes, in an existing tvbuff),
and tvb_new_subset_length_caplen() (for all other cases).
Many of the calls to tvb_new_subset_length_caplen() should really be
calling one of the other routines; that's the next step. (This also
makes it easier to find the calls that need fixing.)
Change-Id: Ieb3d676d8cda535451c119487d7cd3b559221f2b
Reviewed-on: https://code.wireshark.org/review/19597
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Have all dissector tables have a "supports Decode As" flag, which
defaults to FALSE, and which is set to TRUE if a register_decode_as()
refers to it.
When adding a dissector to a dissector table with a given key, only add
it for Decode As if the dissector table supports it.
For non-FT_STRING dissector tables, always check for multiple entries
for the same protocol with different dissectors, and report an error if
we found them.
This means there's no need for the creator of a dissector table to
specify whether duplicates of that sort should be allowed - we always do
the check when registering something for "Decode As" (in a non-FT_STRING
dissector table), and just don't bother registering anything for "Decode
As" if the dissector table doesn't support "Decode As", so there's no
check done for those dissector tables.
Change-Id: I4a1fdea3bddc2af27a65cfbca23edc99b26c0eed
Reviewed-on: https://code.wireshark.org/review/17402
Petri-Dish: Guy Harris <guy@alum.mit.edu>
Reviewed-by: Guy Harris <guy@alum.mit.edu>
João Valverde