[prev in list] [next in list] [prev in thread] [next in thread]
List: wireshark-bugs
Subject: [Wireshark-bugs] [Bug 13827] Numeric Field values defined with BASE_UNIT_STRING do not sort numerica
From: bugzilla-daemon () wireshark ! org
Date: 2017-06-30 23:51:34
Message-ID: bug-13827-15-uWznn0yKPm () https ! bugs ! wireshark ! org/bugzilla/
[Download RAW message or body]
--14988666942.FdbCfE.8586
Date: Fri, 30 Jun 2017 23:51:34 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: https://bugs.wireshark.org/bugzilla/
Auto-Submitted: auto-generated
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13827
--- Comment #7 from Guy Harris <guy@alum.mit.edu> ---
(In reply to Peter Wu from comment #6)
> (In reply to Guy Harris from comment #4)
> > If you use a field with more than one occurrence as a column, you get what
> > you get.
>
> With multiple fields, there is no single correct behavior (you could use
> avg/min/max or pick the an arbitrary field), but consistency seems good. And
> since text columns would be sorted by the prefix, sorting numbers by their
> first occurrence seems good enough imo.
Yes, it's good enough, so if somebody complains about it, point out the issue
and ask them what alternative they'd suggest.
> Multiple occurrences can appear for multiple reasons, including:
> layering/tunneling, reassembly of TCP segments in multiple PDUs, nested
> TLVs. The column can be configured to pick one instead of all of these
> occurrences.
> While not all possible situations can be handled, maybe this is already an
> improvement?
Yes, although this points out that the way we handle custom columns is probably
too simplistic. "Two instances of ip.src because we have layering/tunneling"
is different from "two instances of foobar.tlv.router_id because there are two
router ID TLVs in the FOOBAR message".
> (In reply to Guy Harris from comment #5)
> > (In reply to Peter Wu from comment #1)
> > > One way to solve this is to expose the original numeric value in the
> > > PacketListRecord structure, but that will use slightly more memory (8 bytes
> > > per column per record). That is probably manageable though, especially if it
> > > makes sorting faster (no need to convert a string to a number).
> >
> > Is there one of those *per packet*? Ow.
>
> There may be multiple occurrences, so you need to pick one (for example the
> first). See above discussion.
"Those" in "one of those" is "a PacketListRecord structure", not "a field
value". If there's one of those structures for every packet in the file, it
could be a good target for shrinkage if, for example, some of the values it
contains could be calculated when needed. That's not part of *this* issue, but
it might help when trying to read large files.
--
You are receiving this mail because:
You are watching all bug changes.
--14988666942.FdbCfE.8586
Date: Fri, 30 Jun 2017 23:51:34 +0000
MIME-Version: 1.0
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: https://bugs.wireshark.org/bugzilla/
Auto-Submitted: auto-generated
<html>
<head>
<base href="https://bugs.wireshark.org/bugzilla/" />
<style>
body, th, td {
font-size: 12px;
font-family: Arial, Helvetica, sans-serif; }
p, pre { margin-top: 1em; }
pre {
font-family: Bitstream Vera Sans Mono, Consolas, Lucida Console, \
monospace; white-space: pre-wrap;
}
table { border: 0; border-spacing: 0; border-collapse: collapse; }
th, td {
padding: 0.25em;
padding-left: 0.5em;
padding-right: 0.5em;
}
th { background: rgb(240, 240, 240); }
th.th_top { border-bottom: 1px solid rgb(116, 126, 147); }
th.th_left { border-right: 1px solid rgb(116, 126, 147); }
td.removed { background-color: #ffcccc; }
td.added { background-color: #e4ffc7; }
</style>
</head>
<body>
<p>
<div>
<b><a class="bz_bug_link
bz_status_CONFIRMED "
title="CONFIRMED - Numeric Field values defined with BASE_UNIT_STRING do not sort \
numerically" href="https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13827#c7">Comment \
# 7</a> on <a class="bz_bug_link
bz_status_CONFIRMED "
title="CONFIRMED - Numeric Field values defined with BASE_UNIT_STRING do not sort \
numerically" href="https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13827">bug \
13827</a> from <span class="vcard"><a class="email" \
href="mailto:guy@alum.mit.edu" title="Guy Harris <guy@alum.mit.edu>"> \
<span class="fn">Guy Harris</span></a> </span></b>
<pre>(In reply to Peter Wu from <a href="show_bug.cgi?id=13827#c6">comment \
#6</a>) <span class="quote">> (In reply to Guy Harris from <a \
href="show_bug.cgi?id=13827#c4">comment #4</a>) > > If you use a field with \
more than one occurrence as a column, you get what > > you get.
>
> With multiple fields, there is no single correct behavior (you could use
> avg/min/max or pick the an arbitrary field), but consistency seems good. And
> since text columns would be sorted by the prefix, sorting numbers by their
> first occurrence seems good enough imo.</span >
Yes, it's good enough, so if somebody complains about it, point out the issue
and ask them what alternative they'd suggest.
<span class="quote">> Multiple occurrences can appear for multiple reasons, \
including: > layering/tunneling, reassembly of TCP segments in multiple PDUs, \
nested > TLVs. The column can be configured to pick one instead of all of these
> occurrences.
> While not all possible situations can be handled, maybe this is already an
> improvement?</span >
Yes, although this points out that the way we handle custom columns is probably
too simplistic. "Two instances of ip.src because we have \
layering/tunneling" is different from "two instances of \
foobar.tlv.router_id because there are two router ID TLVs in the FOOBAR \
message".
<span class="quote">> (In reply to Guy Harris from <a \
href="show_bug.cgi?id=13827#c5">comment #5</a>) > > (In reply to Peter Wu from \
<a href="show_bug.cgi?id=13827#c1">comment #1</a>) > > > One way to solve \
this is to expose the original numeric value in the > > > PacketListRecord \
structure, but that will use slightly more memory (8 bytes > > > per column \
per record). That is probably manageable though, especially if it > > > \
makes sorting faster (no need to convert a string to a number). > >
> > Is there one of those *per packet*? Ow.
>
> There may be multiple occurrences, so you need to pick one (for example the
> first). See above discussion.</span >
"Those" in "one of those" is "a PacketListRecord \
structure", not "a field value". If there's one of those structures \
for every packet in the file, it could be a good target for shrinkage if, for \
example, some of the values it contains could be calculated when needed. That's not \
part of *this* issue, but it might help when trying to read large files.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are watching all bug changes.</li>
</ul>
</body>
</html>
--14988666942.FdbCfE.8586--
[Attachment #3 (text/plain)]
___________________________________________________________________________
Sent via: Wireshark-bugs mailing list <wireshark-bugs@wireshark.org>
Archives: https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
mailto:wireshark-bugs-request@wireshark.org?subject=unsubscribe
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic