On 11 January 2007, at 20.15.36, Toby Peterson wrote:

> On 11 January 2007, at 10.42.45, Daniel Stenberg wrote:
>
>> On Thu, 11 Jan 2007, Matt Witherspoon wrote:
>>
>>> I can't personally test it, but I have an idea what the problem
>>> is. I noticed this while fixing the double-copy patch I made --
>>> Curl_read() expects a size_t sizerequested. On my system, size_t
>>> is only 4 bytes long. Try printing out that sizerequested value
>>> in the function -- it is called with the total expected file size
>>> remaining. So if you're requesting a 100MB file, you'll find that
>>> variable will be 100000000.
>>
>> Check again. That fourth argument to Curl_read() is the largest
>> amount of data that is allowed to be read in that call into the
>> given buffer. Since the buffer we use is 16K, 'sizerequested'
>> should never be larger than that...
>>
>> If not, I would say you've found a case where that function is
>> badly used.
>
> It is related to the bytestoread value that's passed to Curl_read
> (). This small patch fixes the issue, though it's a very poor fix:
>
> --- lib/transfer.c.orig 2007-01-11 16:50:33.000000000 -0800
> +++ lib/transfer.c 2007-01-11 17:15:28.000000000 -0800
> @@ -322,7 +322,7 @@
> bytestoread = (size_t)(k->size - k->bytecount);
> /* receive data from the network! */
> - readrc = Curl_read(conn, conn->sockfd, k->buf,
> bytestoread, &nread);
> + readrc = Curl_read(conn, conn->sockfd, k->buf, buffersize,
> &nread);
> /* subzero, this would've blocked */
> if(0 > readrc)

... This didn't paste properly, but you get the idea.

- Toby
Received on 2007-01-12