Date: Tue, 29 Oct 2002 17:11:31 -0800 From: Bill Fenner <fenner@research.att.com> To: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Moving forward with libfetch (was Re: cvs commit: src/lib/libfetch common.c) Message-ID: <200210300111.RAA12355@windsor.research.att.com>
next in thread | raw e-mail | index | archive | help
At this point, I'm hesitant to suggest that we move forward from Alfred's fix until we really understand more. Rev 1.33 says: Fix an infinite loop when _fetch_read() can return 0 (if the connection is broken), take this into account and return at this point. 1.34 says: Back out the previous commit, and fix the bug rather than try to hide its symptoms: make timeouts and short transfers fatal, and set errno to an appropriate value (ETIMEDOUT for a timeout, EPIPE for a short transfer). However, given the linking of _fetch_read and the FILE * that ftp_whatever() returns via _ftp_readfn, _fetch_read() has to be able to indicate EOF; _ftp_readfn expects _fetch_read() to do this in the traditional way of returning 0. The core dumps when _fetch_read() returns an error instead of 0 on EOF indicate to me that _ftp_readfn() is not returning errors to stdio properly (or there is a stdio bug in the funopen() interface). Given that _fetch_read() has to be able to return 0 to permit reading to EOF, is there really something that needs to be improved from rev 1.33? Bill To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200210300111.RAA12355>