From owner-cvs-all Tue Oct 29 17:11:41 2002 Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E4D0537B406; Tue, 29 Oct 2002 17:11:38 -0800 (PST) Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by mx1.FreeBSD.org (Postfix) with ESMTP id 57F5043E42; Tue, 29 Oct 2002 17:11:38 -0800 (PST) (envelope-from fenner@research.att.com) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id 983C54CF75; Tue, 29 Oct 2002 20:11:32 -0500 (EST) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id UAA20301; Tue, 29 Oct 2002 20:11:32 -0500 (EST) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id RAA12355; Tue, 29 Oct 2002 17:11:32 -0800 (PST) Message-Id: <200210300111.RAA12355@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Moving forward with libfetch (was Re: cvs commit: src/lib/libfetch common.c) Date: Tue, 29 Oct 2002 17:11:31 -0800 Versions: dmail (solaris) 2.5a/makemail 2.9d Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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