Coverity has turned up a number of "can't happen" bugs involving
counts or lengths in the kernel going negative -- code that
tests for buf.b_bcount == 0, for instance, and thereafter assumes
that it's greater than zero.

I propose to address the problem by making these members in our
datastructures unsigned.  It's been pointed out that m.len might
be another good candidate.

As far as I can tell there is no code in our system that ever
assigns a negative value to m.len or buf.b_bcount; and there is
certainly code that would severely misbehave if it ever encountered
a buf in that state (I am not familiar enough with the network
code to be able to say the same thing about an mbuf).  Does anyone
have any compelling reason why I should _not_ do this?

The change is sufficiently externally invisible that AFAICT it would
not even require a kernel version number bump.

If there are other structures that have length or count members that
should go unsigned for similar sanity-checking reasons, that would be
a good thing to hear about, as well.

-- 
  Thor Lancelot Simon	                                     tls@rek.tjls.com

  "We cannot usually in social life pursue a single value or a single moral
   aim, untroubled by the need to compromise with others."      - H.L.A. Hart