On Tue, 8 Apr 2003, Juan Ignacio Hervás wrote:

> >Curl_client_write() doesn't use a buffer at all. Are you referring to a
> >particular callback function?

> Yes. You are right. It was my mistake. I was doing debug in fwrite.c (of
> course, it doesn't belong to libcurl).

> I have checked that this situation only happens if I don't use
> CURLOPT_WRITEFUNCTION. In that case, I think, libcurl define its own fwrite
> function and use stdout as the "file" to write.

Not its own really, it then uses the fwrite() funcion in libc (or
equivalent).

> I have attached a simple test source code that get files of a source
> directory with FindFirstFile/FindNextFile API and connect to a remote FTP
> server to check the size of these files.

It looks fine. I'm not running windows so I can't try your particular
program.

> If I don't define any write function (in fact, I don't need it), it fails
> in the second call to Curl_client_write (type=CLIENTWRITE_BODY) : It sends
> to the default write function a 2142 bytes buffer, so the second time it
> calls Curl_client_write, it fails because 2142*2>4096.

Why does it fail because of this? fwrite() is a function your operating
system/compiler provides, and it is supposed to return the number of
successfully written characters. It does not "fill up" buffers and fail.

At least it isn't supposed to.

I can't see how this is a libcurl bug.

> I hope this source code can clarify my problem.

It helped me understand what problem you're experiencing, but it doesn't help
me understand why your fwrite() fails!

-- 
 Daniel Stenberg -- curl, cURL, Curl, CURL. Groks URLs.
-------------------------------------------------------
This SF.net email is sponsored by: ValueWeb: 
Dedicated Hosting for just $79/mo with 500 GB of bandwidth! 
No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/