Comment # 15
on bug 11860
from Guy Harris
(In reply to João Valverde from comment #14)
> (In reply to Guy Harris from comment #12)
> > (In reply to João Valverde from comment #9)
> > > I was suggesting to implement the operators differently: '==' implies OR and
> > > '!=' implies AND. Does that make sense?
> >
> > And what do '>', '>=', '<', and '<=' imply?
>
> This seems more clearcut to me. I think the only meaningful definition of
> '<' is ip.addr < x <=> (ip.src < x AND ip.dst < x). But this does not say
> anything about equality (willing to be proved wrong).
>
> ip.addr is shorthand for the cartesian product of {ip.src}x{ip.dst}.
>From the standpoint of packet-matching expressions, no, it's not. It's just a
field that happens to contain an IP address. All fields are independent
objects, with no special semantics other than their type.
As such, the behavior of the inequality relations on "ip.addr" is the same as
the behavior of the inequality relations on "ip.src" and "ip.dst", so if you
can define a total order on IPv4 addresses, you can define a total order on
"ip.addr" values, just as you can define one on "ip.src" values, "ip.dst"
values, or the values of any other field with a type of FT_IPv4.
Note, however, I said "on "ip.addr" values", not "on "ip.addr". A field does
not have *a* value; an *instance* of a field has a value, and a packet can have
*multiple* instances of the same field. This is not only true of "ip.addr",
it's also true of "ip.src" and "ip.dst" - consider, for example, some form of
tunneling or encapsulation with two layers of IPv4 traffic.
And *all this* also applies to fields of type FT_UINT{n} for various values of
{n}, for which there is most definitely a total order.
You are receiving this mail because:
- You are watching all bug changes.