CNFS offset problems

[bill davidsen]

In article <yly95ensaq.fsf at windlord.stanford.edu>,
Russ Allbery  <rra at stanford.edu> wrote:
| 
| bill davidsen <davidsen at tmr.com> writes:
| 
| >   If we write this as:
| >     article.len > cnfs->length - cnfs->free - CNFS_BLOCKSIZE - 1
| > the RHS can go negative, but if we write it as
| >     (article.len + CNFS_BLOCKSIZE + 1) > (cnfs->length - cnfs->free)
| > I think both side have to be positive and will happily compare. No
| > comments about extra parens, people have to read code as well as
| > compilers.
| 
| I almost did that, but then realized that this breaks for a 2GB article in
| a particularly nasty way (article.len + CNFS_BLOCKSIZE + 1 overflows and
| wraps to a small positive number, so CNFS thinks there's enough space for
| the message).

A 2GB article?!!! I thought I had problems with users complaining that
they spent hours uploading a uuencoded CD as a single post and it was
rejected, does someone really allow 2GB?

And why would it break? Since article.len is unsigned the LHS should be
evaluated as unsigned, should it not? It's the RHS which is signed, I
thought.
-- 
bill davidsen <davidsen at tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.