Comment 3 for bug 1502170

Hm,

the operator "&&" is defined in rfc 4997 as:

4.7.4. Boolean Operators
   o &&, for logical "and". Returns true if both arguments are true.
      Returns false otherwise.

and

4.7. Expressions
   o There are no bitwise operators.

;-)

This make no sense for this:

tcp_opt_sack(ack_value)
{
  UNCOMPRESSED {
    block_1 [ 64 ];
  }

  COMPRESSED sack2_list_item {
    block_2 =:= sack_block(block_1.UVALUE && 0xFFFFFFFF);
  }
}

There are no boolean values involved at all.
However, I interpreted "&&" as the C operator "&" (bitwise and).
Then I think the "&& 0xFFFFFFFF" should use the lower 32bit
from the 64bit sized block_1 and omit the higher 32bit.
That is the way how it works in C.
And if

  UNCOMPRESSED {
    block_start [ 32 ];
    block_end [ 32 ];
  }

are ordered from left to right, then
the lower 32bit are block_end.
Your are right.
Then I thought too long about this on a Friday evening...
This is the correct version:

  const uint32_t base = ((i == 0) ? ack_num : rohc_ntoh32(decoded->blocks[i-1].block_end));

Best,
Klaus Warnke