Assign result of `register_dissector(..., func, proto)` to FOO_handle
and remove `FOO_handle = create_dissector_handle(func, proto)`.
Found by looking for files named packet-FOO.c having the above
create_dissector_handle pattern. Some files (with different dissect
routines for the two functions) remain unchanged.
Change-Id: Ifbed8202c6dbc63a1dae9acc03313980ffbbbb90
Reviewed-on: https://code.wireshark.org/review/13247
Reviewed-by: Peter Wu <peter@lekensteyn.nl>
Petri-Dish: Peter Wu <peter@lekensteyn.nl>
Reviewed-by: Michael Mann <mmann78@netscape.net>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Change-Id: Ie39ef054a4a942687bd079f3a4d8c2cc55d5f22c
Reviewed-on: https://code.wireshark.org/review/12485
Petri-Dish: Michael Mann <mmann78@netscape.net>
Reviewed-by: Michael Mann <mmann78@netscape.net>
Some of the ASN.1 dissectors still generate a new_create_dissector_handle from the tool itself, so leave those for now.
Change-Id: Ic6e5803b1444d7ac24070949f5fd557909a5641f
Reviewed-on: https://code.wireshark.org/review/12484
Petri-Dish: Anders Broman <a.broman58@gmail.com>
Reviewed-by: Michael Mann <mmann78@netscape.net>
Picking off "easy" dissectors that only have one or two exit points at most.
Change-Id: I3d5e576b796556ef070bb36d8b55da0b175dcba8
Reviewed-on: https://code.wireshark.org/review/11805
Petri-Dish: Michael Mann <mmann78@netscape.net>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Michael Mann <mmann78@netscape.net>
It's complaining about an "overflow in constant arithmetic". Neither
INFINITY nor NAN are specified by C90; C99 specifies that they are both
floats. Until recently, Microsoft had no interest in C99; if the
version we're using supports C99's INFINITY and NAN, it should be OK to
assign them to a variable (no "arithmetic" involved), so I'm guessing
that the "arithmetic" in question is the use of conditional operators ?
and :, so I'm writing it as an if statement instead.
Change-Id: I532b9b5943be32e0897e4f03ac4e625ac41ee63b
Reviewed-on: https://code.wireshark.org/review/10215
Reviewed-by: Guy Harris <guy@alum.mit.edu>
64-bit integers are *not* guaranteed to be longs and, in fact, are *not*
longs on ILP32 platforms such as 32-bit UN*Xes and 32-bit Windows and on
LLP64 platforms such as 64-bit Windows.
Change-Id: I6408778f638bb6cea52ffb64be39ea26c9b2ee64
Reviewed-on: https://code.wireshark.org/review/10213
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Spell out "mantissa" while we're at it.
Change-Id: I47ddb9882f45ef58a6f7101818683e68bc54983b
Reviewed-on: https://code.wireshark.org/review/10211
Reviewed-by: Guy Harris <guy@alum.mit.edu>
This adds a dissector Concise Binary Object Representation (CBOR) (RFC 7049).
CBOR is a binary data format designed for implementations with small
code size as used in the IoT. It uses a structure similar to JSON, but
encodes the data in binary format. This is used on top of CoAP for
example.
Change-Id: I9d7b7d4f7609c899bfc68250cdfebd5dc64e0402
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Reviewed-on: https://code.wireshark.org/review/9848
Reviewed-by: Michael Mann <mmann78@netscape.net>
Petri-Dish: Michael Mann <mmann78@netscape.net>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Pascal Quantin <pascal.quantin@gmail.com>
Peter Wu