tcp: Avoid SEQ_*() comparisons against 0

Usually we use the SEQ_{LT,LE,GT,GE}() comparison macros on raw sequence
numbers, to see how they related handling possible wraparounds.  However,
in two cases we take a difference of sequence numbers then compare that
difference to 0.

As long as the difference is done using wrapping unsigned arithmetic,
that's not incorrect.  It's essentially doing comparisons in a "shifted"
space of sequence numbers, and I find working in both the raw and shifted
spaces makes it harder to reason about.  Specifically I sometimes find I
have to go through an additional layer of logic to convince myself that the
wraparound handling is correct.

In addition to confusing me, it also tends to confuse cppcheck, at least in
cppcheck 2.21.0 it often seems to trip false positives via cppcheck bug
14848.

It turns out that in each of the cases we use comparisons of sequence
differences against 0, it's pretty much just as clear - maybe clearer to
perform the comparisons against raw sequence numbers.  We still need the
difference afterwards, but it's much more obvious that it means what we
need it do, if we've already eliminated cases where the sequence numbers
aren't in the expected order.

In the case in tcp_data_from_tap() this also lets us simplify the diagram
explanation of the different cases a bit.  While there we correct the
diagram in the second discard case: seq was shown as partway into the
packet, which is not true by definition.  Instead seq_from_tap should be
some distance after the end of the packet.

Link: https://trac.cppcheck.net/ticket/14848
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>

0 files changed, 0 insertions, 0 deletions