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