[Http-crcsync] Small fix in crcsync.c

[Alex Wulms]

Hi Rusty,

While analyzing if crcsync supports a tail block that is larger then 
the 'normal' blocks, I stumbled accross a small bug in the code.

In attachment you can find a fixed version of the code and a test program that 
demonstrates the issue. The issue only occurs if you feed the 
crc_read_block() function with chunks that are smaller then the blocksize and 
at the same moment you start with some non-matching data. I was already aware 
of some issue with feeding small blocks of data (I have worked around it in 
the server code) but never dug deep enough into the code to understand where 
the issue came from.

While I was fixing the code, I have also refactored it here and there to 
become slightly simpler.

As a next step, I will enhance the code to support matching a tail block that 
is larger then the normal blocks (does not work at the moment) and to match a 
tail block that follows some literal/non-matching data, which is explicitly 
not supported at the moment. This was not an issue when the tail block was 
only a few bytes (the tail block would be treated as literal data in such 
case but it was only a few bytes overhead) but now that we have a tail block 
that is a merge of a full-block + some trailing bytes, it is no longer a 
small overhead and should be supported. I'll send you that code as well once 
it is completed, so that you can retrofit in into ccan.

Kind regards,
Alex

-------------- next part --------------
A non-text attachment was scrubbed...
Name: test_hash_small_invokations.c
Type: text/x-csrc
Size: 951 bytes
Desc: not available
Url : http://lists.laptop.org/pipermail/http-crcsync/attachments/20091230/9e2a621c/attachment.c 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: crcsync.c.fixed
Type: text/x-csrc
Size: 7226 bytes
Desc: not available
Url : http://lists.laptop.org/pipermail/http-crcsync/attachments/20091230/9e2a621c/attachment-0001.c