Submitter: Anders Broman (a.broma...@gmail.com)
Changed: branch: master
Repository: wireshark


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

Reply via email to