In article <20060414021659.GA15652@panix.com>,
Thor Lancelot Simon  <tls@rek.tjls.com> wrote:
>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.

I have a kernel where I have made these changes but it does not boot...
If anyone wants to debug it, I can put it up for anonymous ftp. This
kernel passes -Wsign-compare...

christos