URL:
https://code.wireshark.org/review/gitweb?p=wireshark.git;a=commit;h=b6a2915d0d5a7ab1524a49b216290f1e33feb19b
Submitter: Anders Broman (a.broma...@gmail.com)
Changed: branch: master
Repository: wireshark
Commits:
b6a2915 by Peter Wu (pe...@lekensteyn.nl):
mate: fix Match edge cases, improve documentation
Use strcmp to sort AVPs in an AVPL and for matching instead of comparing
pointer addresses. Pointers can only be used for (in)equality, there is
no ordering in them. Matching of attributes however requires a better
ordering to know whether the operator (condition) or whether the operand
(data) can be skipped. Otherwise it is possible that condition (b)
randomly fails to match data (a,b).
User-visible changes (mainly edge cases):
- Loose (a=1, a?) on data (a=0, a=1) would previously fail to return
(a=0,a=1) because the a? condition is not tried for data a=0. Now it
tries all compatible conditions for a data AVP.
- Any Match condition like (a=1, a^1) would previously be treated the
same as (a=1) while (a^1, a=1) would still be seen as (a^1, a=1). The
first case is now fixed to match (a=1, a^1). (Via a fix in insert_avp
to ensure that (a=1) is not considered the same as (a^1).)
- Every (a=1, a=2) on data (a=1, b=1) previously failed, but the
comment "it will not create a list if there is not a match for every
attribute in op" suggests that it should return (a=1).
- Every (a=1) on data (a=2) previously succeeded (bug) while it would
fail on (a=2, b=1). This is fixed now by checking whether any of the
conditions really have matching data for the attribute.
Other changes: optimize merge_avpl and new_avpl_*_match to insert in
linear time instead of quadratic, rewrite and add comments in an attempt
to make it easier to understand. Merge the new_avpl_every_match and
new_avpl_exact_match functions and rename it to new_avpl_pairs_match to
reflects its actual implemented functionality.
Not addressed in this patch is the quasi-randomness of the returned
data AVPL. AVPLs are unordered, so the condition Strict (a?) on data
(a=1, a=2) could in theory return either (a=1) or (a=2). In practice
this returns (a=1) because of alphabetical ordering, but this cannot
really be relied on. It gets worse for conditions like Strict (a?, a>1),
these are considered undefined behavior (without warnings for now).
Ping-Bug: 12184
Change-Id: I0008448ffcb96183f106cb937c4f488e26a82f92
Reviewed-on: https://code.wireshark.org/review/17777
Petri-Dish: Alexis La Goutte <alexis.lagou...@gmail.com>
Tested-by: Petri Dish Buildbot <buildbot-no-re...@wireshark.org>
Reviewed-by: Michael Mann <mman...@netscape.net>
Reviewed-by: Alexis La Goutte <alexis.lagou...@gmail.com>
Reviewed-by: Anders Broman <a.broma...@gmail.com>
Actions performed:
from 064f4d1 eap: dissect eap wlan identity.
adds b6a2915 mate: fix Match edge cases, improve documentation
Summary of changes:
plugins/mate/mate_runtime.c | 14 +-
plugins/mate/mate_util.c | 438 +++++++++++++++++--------------------------
plugins/mate/mate_util.h | 12 +-
3 files changed, 184 insertions(+), 280 deletions(-)
___________________________________________________________________________
Sent via: Wireshark-commits mailing list <wireshark-commits@wireshark.org>
Archives: https://www.wireshark.org/lists/wireshark-commits
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-commits
mailto:wireshark-commits-requ...@wireshark.org?subject=unsubscribe
