| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
For a sane plugin build environment. Include config.h as the first
header in the .c file instead.
Fix by moving required compiler attribute macros to a new
"ws_attributes.h" API header.
Change-Id: I34f58a927f68c1a0e59686c14d214825149749e1
Reviewed-on: https://code.wireshark.org/review/23400
Petri-Dish: João Valverde <j@v6e.pt>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: João Valverde <j@v6e.pt>
|
|
‘epl_wmem_iarray_is_empty/sorted’ [-Wredundant-decls]
Change-Id: Ia969ffddc0035b18e7a4afc67d0c830f082938ea
Reviewed-on: https://code.wireshark.org/review/22103
Petri-Dish: Alexis La Goutte <alexis.lagoutte@gmail.com>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Anders Broman <a.broman58@gmail.com>
|
|
function declaration [-Wdocumentation]
Change-Id: I76a7c66fd4d1872b5cc63447b5acfac2ab8821fd
Reviewed-on: https://code.wireshark.org/review/21981
Reviewed-by: Roland Knall <rknall@gmail.com>
|
|
Just as we have OD_ENTRY_INITIALIZER, add SUBOBJECT_INITIALIZER, and use
it rather than memset().
Whether removing initializer warnings is a Good Thing is subject to
debate; remove a comment that implies it's been deemed a Good Thing.
Change-Id: Ife658d8bb1d4868789ca3b929aff6e4fccecb430
Reviewed-on: https://code.wireshark.org/review/21892
Reviewed-by: Guy Harris <guy@alum.mit.edu>
|
|
macOS Buildbot doesn't like {0} (probably because GNU C already provides {}
exactly for the purpose of initializing all members to zero/NULL/0.0.. etc)
Affected local type definitions now have a static intializer macro that uses
the correct amount of zeroes and braces (similar to PTHREAD_MUTEX_INITIALIZER)
Global type definitions have a memset to zero (Which isn't strictly correct,
but as the platforms we support all have all-bits-zero-nulls and IEEE 754
floats, it should be good enough. A separate change will attempt to disable
-Wmissing-field-initializers -Wmissing-braces globally and hopefully make
these workarounds unnecessary.
Change-Id: I30b0f679bbb8adb2dd7269c9f3bc19732e48212b
Reviewed-on: https://code.wireshark.org/review/21887
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Guy Harris <guy@alum.mit.edu>
|
|
Cyclic PDOs are setup either by ObjectMappings in the asynchronous SDOs,
or by serialized ObjectMappings in device profile files.
We now keep track of ObjectMappings transmitted via SDOs or read from
XDC files and use those to correctly partition the PDO's payloads.
Additionally types and descriptions for Object Directory entries extracted
from the EDS and XDD profiles are used to select the correct Wireshark type
and a string representation for those partitoned PDOs. Other places where
indices and subindices are also enriched by this information.
EDS support leverages GKeyFile and is available unconditionally, XDD/XDC
parsing support depends on the availabilty of libxml2. A patch for
inclusion of the latter as optional dependency was submitted
as Change-Id: I13c0a2f408fb5c21bad7ab3d7971e0fa8ed7d783
Electronic Data Sheet (EDS) is the CANopen standard for device profiles,
POWERLINK being based on CANopen, is occasionly used with EDS profiles.
XML Device Description (XDD) is the Ethernet POWERLINK standard for
device profiles. XDC have the same structure but contain actualValues
fields which can contain default ObjectMappings.
XML Device Descriptions can be 25k+ lines with much duplication,
so wmem_iarray_t is leveraged for saving space as well as faster lookups.
A side-effect of now organizing the capture in conversations is that
POWERLINK over UDP packets are now assigned proper destination and source
node IDs, which are displayed in the column view. The Referenced bug where
packets where erronously flagged as duplicates because the address wasn't
considered is also fixed as a result.
Bug: 13604
Bug: 13749
Change-Id: Ic33ff0be8f2eae7c24fe5877ad9258d1e550c227
Reviewed-on: https://code.wireshark.org/review/21112
Petri-Dish: Peter Wu <peter@lekensteyn.nl>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Peter Wu <peter@lekensteyn.nl>
|
|
A sorted array keyed by intervals
You keep inserting items, then sort the array.
sorting also compacts items that compare equal into one and adjusts
the interval accordingly. find uses binary search to find the item
This is particularly useful, if you got many similar items,
e.g. ObjectMapping subindices in the XDD. XDDs can be upward of
25k lines long with much duplication (253 subindices having the same
content).
Interval Trees wouldn't work, because they didn't allow expanding
existing intervals. Using an array instead of a tree, additionally offers
a possible performance advantage, but it's not that critical here,
as finding should only happen in the async frames
There's room for optimization in the creation process of the array,
but it doesn't matter much, as they aren't created frequently.
Finding speed is what matters for the use case of parsing EDS
and XDD files
Change-Id: Iaaddc90059f0e49b456774a111d8d42452b90cf9
Reviewed-on: https://code.wireshark.org/review/21111
Petri-Dish: Peter Wu <peter@lekensteyn.nl>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Peter Wu <peter@lekensteyn.nl>
|
