yamt@mwd.biglobe.ne.jp said:
> portability thing? iirc, it was for correct operations, not for
> portability. 

OK, I see that there is another case where the signed/unsigned
makes a difference: division.
So you are right, it is not just about the ">>" portability.

Well, the documentation isn't clear in this respect:
At one point it says:
  P[i:n] gives the data at byte offset
  ``i'' in the packet, interpreted as a word (n=4), unsigned halfword (n=2),
  or unsigned byte (n=1).
The halfword and byte are explicitely unsigned, the "word" not.
This might however not refer to arithmetics but just to the fact
that no sign extension happens when a shorter value is loaded
into the accumulator.
There is also the BPF_NEG which wouldn't make much sense in a
strictly unsigned world.
Otoh, since the kernel does unsigned arithmetics and has always
done, I'd definitely expect that the userland filter behaves
identically.
I somehow believe that almost noone does arithmetics on values
which use up the 32 bits, let alone division. That's why
noone really cares...

best regards
Matthias