On Sun, 18 Jan 2004, Joe Halpin wrote:

> > Just note that having the (void)s there is not very nice code. Actually
> > caring about errors is better.
>
> Normally I do. However, the only error I can see that would occur is for the
> server to have closed its end of the connection (for example, crashing in
> the middle of a send).

Yes, and then it would be unnecessary to attempt to read the response. It
could also time-out (both the send and the read).

> I had thought that Curl_read() would detect that, but looking at it again I
> see that it doesn't return a value of 0, so there isn't any way of telling
> that the server has dropped the connection. I'll have to think about that a
> bit more.

It returns the size of the read data (in the 5th argument's pointed-to data),
which indeed is 0 if you didn't get any. It also returns an error code for
errors, and CURLE_OK if everything is OK.

> > FTP-specific disconnect code should be written in the Curl_ftp_disconnect()
> > function (which is called from the Curl_disconnect()) function.
>
> How would I tell in Curl_ftp_disconnect() whether it was the control or data
> connection that was being closed? That's been the hardest thing for me to
> figure out, and is why I put it where I did. Currently nothing is actually
> disconnected in Curl_ftp_disconnect() so it's hard to make the distinction
> there, while it seems easy in Curl_disconnect().

Since Curl_ftp_disconnect() is always called from Curl_disconnect() (when FTP
is used), there is no difference in logic as to when this function is called.
It just makes it properly called for FTP connections only.

> I'm not very familiar with the library though. I suspect you're correct
> about calling Curl_ftp_quit() at the wrong point. Would it be ok for me to
> add a parameter to Curl_ftp_disconnect() which indicates whether or not an
> ftp control connection is being closed? Then I could know when to call
> Curl_ftp_quit().

This disconnect is always referring to the control connection. The data
connection is treated differently.

> Incidentally, I tried running this with the memory debug option on but got
> no output file.

You need to give me some more info. What did you do to get an output file? If
you build a full curl tool with --enable-debug, you get a curl binary that
produces an output file (named 'memdump') if the environment variable
CURL_MEMDEBUG is set.

If you don't do that, you need to invoke curl_memdebug() in your own way to
initialize the memory debug system.

> Is there any way to build this to use Electric Fence?

Sure, just add the -lefence lib to the LIBS.

Another option is to run your tests with valgrind, which is a better tool than
Electric Fence.

Both the memory debug stuff and valgrind are used if you use the runtests.pl
perl script to run tests ('make test' in the build root is good enough). Try
the tests 100 to 139, they all do FTP transfers and most of them will be
affected by your work.

The valgrind usage by the runtests.pl will only produce a 'valgrind[num]' file
in the log/ dir for human interpretation. There is currently no automatic
scanning/reporting of errors detected by valgrind. Mostly because valgrind
always complains A LOT about flaws in openssl and when developing curl I
really don't care about openssl problems... :-)

-- 
    Daniel Stenberg -- http://curl.haxx.se/ -- http://daniel.haxx.se/
   [[ Do not send mails to this email address. They won't reach me. ]]
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn