https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=8718
More zigbee dissection, adding the following clusters:
- appliance identification
- meter identification
- appliance statistics
- appliance events and alert
svn path=/trunk/; revision=50202
on a Mac, right? So of *COURSE* you want to use our shiny new frameworks
rather than those ugly old open-source multi-platform libraries, right?"
warnings.
svn path=/trunk/; revision=50200
Create generic int/uint fill functions from hfinfo_[u]int_value_format.
XXX: to be honest I don't get it why if dev picked up BASE_DEC_HEX and has value string we're truncating it to BASE_DEC...
svn path=/trunk/; revision=50197
... as per the XXX comment removed from tshark.c this was a mess to keep the linker
happy... I couldn't!
I did this without even understanding whether calling main_window_update was realy
necessary in most cases. I guess nothing or more specific update cbs would be best.
svn path=/trunk/; revision=50188
bugs it points out that probably mean the code won't work on machines
that require alignment (e.g., SPARC machines), but we'll turn it on once
we fix them. (clang is fussier than GCC about this.)
svn path=/trunk/; revision=50187
From the comment above wmem_tree_insert32_array():
* If you use ...32_array() calls you MUST make sure that every single node
* you add to a specific tree always has a key of exactly the same number of
* keylen words or things will most likely crash. Or at least that every single
* item that sits behind the same top level node always have exactly the same
* number of words.
So clearly generating thousands of keys with random lengths while testing is
going to cause problems. Generate a set of random lengths, then use those
lengths consistently (but still generating random keys of those lengths).
Should hopefully fix the intermittent build-bot failures.
(unfortunately this does not manifest nicely, and I cannot see an easy way to
assert it so that we catch other people trying to use different-length key
subtrees)
svn path=/trunk/; revision=50184
According to ETSI TS 102 771 (GSE implementation guidelines), "mandatory extension headers" - when GSE's protocol type field is (strictly) less than 256 (0x100) - are of 'pre-defined length (and format) that must be known by all GSE receivers'.
svn path=/trunk/; revision=50180
an error, or not issue warnings, by default if you give them an unknown
-f flag. Instead, test that flag with all compilers, and use -Werror to
force it to error out.
As with C/C++ flags, so with C++-only flags.
svn path=/trunk/; revision=50178
Enable INET6 checking on Solaris versions other than 5.8.
(Yes, theoretically this should be checking for Solaris 5.7 or later. I'm
going to go out on a limb and assume that no one is actually still using 5.7
or, if they are, they aren't trying to compile a modern Wireshark on it...)
svn path=/trunk/; revision=50173
against the Gtk+ libraries.
(I didn't notice this before because the resulting programs aren't, on my
system, actually linked against the libraries they don't use--presumably
because of the "-Wl,--as-needed" flag.)
svn path=/trunk/; revision=50170
Evan Huus