| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Add UTF-8 constants for greek capital delta.
|
|
|
|
Extcaps are in their own subdirectory, so trim_progfile_dir trims that
off in that case to return the common program file directory.
Extcaps are now in a namespaced subdirectory, so we trim that off first
before looking to see if the next directory name matches "extcap".
However, if it's not an extcap directory, then restore the supposed
namespaced subdirectory. It could be "wireshark" from some other path,
particularly from \Program Files\wireshark (which, since Win32
GetModuleFileName doesn't "correct" the case of paths passed in on
the command line, can also happen if Wireshark is installed to the
default location.)
Fix #20057
|
|
CMake recommends that the various CMAKE_INSTALL_<dir> variables
be relative paths, and we have been assuming that they are.
Absolute paths are technically allowed.
Work around absolute paths, and just don't look for the doc
dir, etc. in relocated paths if they are.
Fix #20055
|
|
|
|
Closes #20010
|
|
This tag is needed by some dissectors to find the direction.
Ping #20012
|
|
|
|
Add UTF-8 constants for greek omega (upper and lower case) and for
subscript zero.
|
|
There were a few places that used gboolean FALSE
in places where a pointer was expected to mean NULL.
gboolean FALSE being an int 0, this worked.
Both gcc and clang will error if compiled in C23 mode with
this (in C99 until C23, false is a macro constant that
expands to the integer constant 0; false has type int so
this is still legal; in C23 false has type bool and gcc
and clang warn about implicit conversions of bool to
pointers.)
Replace the calls with NULL.
Ping #19116
|
|
Signed-off-by: Yaniv Kaul <mykaul@gmail.com>
|
|
Note that this is somewhat less than useful when run from
the Finder on macOS (returns the root directory) or from
a shortcut (including the taskbar) on Windows (returns whatever
is set as the fixed "run in" directory for the shortcut, which
is usually the directory where the program resides, certainly
for the shortcut the installer sets up.)
We could try to do the same kind of workaround as done in
get_persdatafile_dir() and for the other file open style settings.
OTOH, this isn't the default setting (as platform UI guidelines
recommend against this sort of thing on macOS and Windows), so
perhaps caveat emptor is ok here.
Fix #1237
|
|
|
|
Give the "FILETIME, but with nanosecond resolution" routine a name
similar to the "FILETIME, but with second resolution".
|
|
Have one dissector, in epan/dissectors/packet-windows-common.c, for each
of:
* NTTIME - a 32-bit lower half of a 64-bit value, followed by a 32-bit
upper half of that 64-bit value. The result is a count of
100-nanosecond units since the FILETIME epoch.
* NTTIME_hyper: a 64-bit value, which is a count of 100-nanosecond units
since the FILETIME epoch.
* NTTIME_1sec: a 64-bit value, which is a count of *seconds* since the
FILETIME epoch.
Each of thos takes an encoding value to indicate what byte order the two
32-bit values in an NTTIME, or the 64-bit value in an NTTIME_hyper or an
NTTIME_1sec, are in.
Don't have those dissectors return the new offset, have them return the
new protocol tree item. The size, in the packet, of those items is
always 8 bytes, so we can just increment it in the caller, but some
callers want the item, and this is more convenient than returning it
through a pointer.
Have DCE RPC dissectors for each of those types, using the data
representation to select the byte order to pass to the
previously-mentioned dissectors. Update pidl to use the appropriate one
of those dissectors for those three types.
Add a filetime_1sec_to_nstime() routine to convert a 64-bit
seconds-since-the-FILETIME-epoch value to an nstime_t, and use it in the
NTTIME_1sec dissector.
Get rid of nt_time_to_nstime(); just directly call filetime_to_nstime().
That removes a check for the upper 32 bits of the FILETIME being 0, so
some values will now be converted rather than giving "Time can't be
converted" errors.
|
|
* guint32_to_str_buf() -> uint32_to_str_buf()
* guint64_to_str_buf() -> uint64_to_str_buf()
* guint64_to_gdouble() -> uint64_to_double()
* gdouble_to_guint64() -> double_to_uint64()
* get_nonzero_guint32() -> get_nonzero_uint32()
* get_guint32() -> get_uint32()
* guint8_to_hex() -> uint8_to_hex()
|
|
|
|
Supported types: CGI, ECGI, NCGI.
|
|
|
|
As README.developer says:
"Avoid GLib synonyms like gchar and gint and especially don't use
gpointer and gconstpointer, unless you are writing GLib callbacks and
trying to match their signature exactly. These just obscure the code and
gconstpointer in particular is just semantically weird and poor style."
We didn't convert gconstpointers in convert-glib-types.py until
5f807da9ba, so make another pass and do so on everything except our
dissector code. Convert some gpointers as well.
Ping #19116
|
|
|
|
The HTML documentation our macOS bundles is in the datafile directory.
|
|
There's nothing in the wiretap packet reading or writing code,
as used by editcap, that cares about the packet number and thus
there's no need to limit editcap to a 32 bit number of frames.
Indeed, if one has such an enormous file, an obvious thing to
try to do is to use editcap to split it into sizes that can be
handled by tshark (2^32 - 1) or Wireshark (2^31 - 1).
Fix #16122
|
|
Add constant UTF8_SQUARE_ROOT for UTF-8 square root.
|
|
This Glib macro uses __attribute__((alloc_size(n))) to aid static analysis of
buffer bounds. Using it on wmem_alloc, wmem_alloc0, wmem_realloc and
wmem_memdup gives the compiler's static analyzer a chance to detect
out-of-bounds accesses to the buffers they return.
It would be nice to extend this to some of the tvb functions, but the tvb API's
use of length -1 to indicate "to the end of the tvbuff" gets in the way.
This annotation surfaced the issue addressed in commit 54410038.
|
|
The VC++ analyzer reports several instances of warning C6323 for the use of
arithmetic operators on Boolean types.
In each case, the Boolean value is being multiplied by two. "boolVal * 2" can
be trivially replaced with "boolVal ? 2 : 0".
|
|
|
|
The documentation for GCC's __attribute__((malloc)) [1] says specifically that
this attribute should not be used on realloc-like functions because "they may
return pointers to storage containing pointers to existing objects" which can
cause the compiler to make incorrect assumptions about pointer aliasing, so
let's remove G_GNUC_MALLOC from wmem_realloc.
wmem_memdup meets the same criterion, so G_GNUC_MALLOC is removed from that
function too.
[1] https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#index-functions-that-behave-like-malloc
|
|
8541041922 moved extcaps to a namespaced subdirectory on Windows, so we
need to account for that elsewhere.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
file_wrapers.c converted, crude test give half the time to open .gz
file.
Rased https://github.com/zlib-ng/zlib-ng/issues/1743 for gz, as a
workarond edit zlib-ng.h
|
|
Use "event" if we're running Logray.
|
|
|
|
|
|
|
|
This wide-ranging change replaces the vast majority of instances of the "sizeof
arr / sizeof (TYPE)" pattern (and a few more "sizeof arr / sizeof var", "sizeof
arr / sizeof arr[1]", etc.) with the array_length macro.
A small number of cases of "sizeof arr / sizeof (TYPE)" remain; These appear to
be legitimate divisions of some array/variable's size by the size of some
_other_ TYPE unrelated to the array/variable type -- i.e. computing number of
records/samples which will fit in a given buffer.
A few unused variables/macros were removed instead of being updated.
Trivial formatting changes were made in a few places.
As with the previous part of this cleanup, comparison of the built object files
confirms that most of the changes have no net effect and the few actual changes
are trivial and harmless. Some changes are apparent in debug info (to be
expected), in __LINE__ values (also to be expected), and the simplification in
the opcua plugin is reflected in slightly simpler generated code.
|
|
Fix array.h missing in debian packaging:
In file included from debian/headers-check.c:14:
debian/libwireshark-dev/usr/include/wireshark/epan/packet.h:15:10: fatal error: wsutil/array.h: No such file or directory
|
|
A "sed" script was used to replace all occurrences of "sizeof arr / sizeof
arr[0]" (including one pair of brackets surrounding the whole expression, if
present, and including brackets around the argument to "sizeof", if present)
with an "array_length(x)" macro invocation.
A handful of more complex cases were manually edited.
The resulting code should be identical -- with the exception of a few trivial
details such as __LINE__ values and the precise formatting of assertion
messages.
No attempt has yet been made to address expressions of the form "sizeof arr /
sizeof (TYPE)"; These would probably require manual handling to confirm that
the named TYPE indeed corresponds with the type of the array element.
|
|
There are several definitions of g_ptr_array_len and array_length scattered
around, and there are some files which include epan/proto.h or epan/packet.h
just for those definitions alone.
The definitions have been moved to a new wsutil/array.h, existing definitions
removed, and #includes amended to suit.
|
|
Add an epoch value for the Zigbee ZCL epoch - 2000-01-01 00:00:00 UTC -
to wsutil/epochs.h, and use that.
Add a time stamp format consisting of a 4-byte or 8-byte count of
seconds since that epoch, ENC_TIME_ZBEE_ZCL, and use that instead of
manually extracting the value, constructing an nstime_t, and adding that
value.
|
|
Define 2 reserved fields in PeekremoteV0.flags field to carry band
information, and compute frequency based on <band, channel number>. This
ensures that correct frequency is refelcted in 802.11 radio information,
as well as facilitates decoding of MCS_NSS field in EHT Capabilities IE.
Closes #19792.
|
|
This reverts commit 90b16b40921b737aadf9186685d866fd80e37ee6.
|
|
This reverts commit 60f1972fa3700d8d702e0f9b0df6ec1980d97ecb.
|
|
This reverts commit 0b2bb4fdb3b74b3b713ae26134d9e23673def875.
|
|
This reverts commit 869728143da68a32a9420bc932006c0863bd9544.
|
