CNFS offset problems

bill davidsen davidsen at tmr.com
Tue Jan 21 15:01:43 UTC 2003


In article <ylu1g3ld9h.fsf at windlord.stanford.edu>,
Russ Allbery  <rra at stanford.edu> wrote:
| 
| Russ Allbery <rra at Stanford.EDU> writes:
| 
| > Hm.  Not sure where to start looking for this one.  I guess I can go try
| > to understand the code that detects that a cycbuff is full.
| 
| I hate C integer promotion.
| 
| In the comparison:
| 
|   if (article.len > cnfs->length - cnfs->free - CNFS_BLOCKSIZE - 1)
| 
| if cnfs->length - cnfs->free (which are both off_t), representing the free
| space left in the cycbuff, is greater than CNFS_BLOCKSIZE + 1 (if, in
| other words, there aren't at least two blocks free), the right hand side
| is negative, since off_t is signed.
| 
| If off_t is larger than size_t (the type of article.len), which is the
| common case for large files since off_t is then a 64-bit type, everything
| gets promoted to off_t and this works fine.
| 
| If off_t and size_t are both the same size (32 bits or 64 bits), then the
| signed type (off_t) is promoted to unsigned to match, and the negative
| value on the right hand side becomes a large positive number, thus making
| INN think there's room left in the cycbuff.

  I guess the real question which comes to my mind is why the article
length is unsigned in the first place. I usually keep a write write
pointer and space left pointer when I do circular buffers, just because
I'm lazy about stuff like this. Bit late for that now...
-- 
bill davidsen <davidsen at tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.


More information about the inn-workers mailing list