From owner-p4-projects@FreeBSD.ORG Sun Jul 15 22:07:53 2007 Return-Path: X-Original-To: p4-projects@freebsd.org Delivered-To: p4-projects@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 32767) id 39D8516A405; Sun, 15 Jul 2007 22:07:53 +0000 (UTC) X-Original-To: perforce@freebsd.org Delivered-To: perforce@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 10C3516A400; Sun, 15 Jul 2007 22:07:53 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mxout4.cac.washington.edu (mxout4.cac.washington.edu [140.142.33.19]) by mx1.freebsd.org (Postfix) with ESMTP id E270713C474; Sun, 15 Jul 2007 22:07:52 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.7] (may be forged)) by mxout4.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.06) with ESMTP id l6FM7oe5020696 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 15 Jul 2007 15:07:50 -0700 X-Auth-Received: from [192.168.10.45] (c-24-10-12-194.hsd1.ca.comcast.net [24.10.12.194]) (authenticated authid=youshi10) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l6FM7njN012100 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 15 Jul 2007 15:07:49 -0700 Message-ID: <469A9AB4.6050702@gmail.com> Date: Sun, 15 Jul 2007 15:07:48 -0700 From: Garrett Cooper User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: "M. Warner Losh" References: <200707152008.l6FK8Nr8028280@repoman.freebsd.org> <20070715.150629.-457441111.imp@bsdimp.com> In-Reply-To: <20070715.150629.-457441111.imp@bsdimp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 5.3.2.304607, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.7.15.144733 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='FORGED_FROM_GMAIL 0.1, __CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __FROM_GMAIL 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' Cc: perforce@freebsd.org, gcooper@freebsd.org Subject: Re: PERFORCE change 123550 for review X-BeenThere: p4-projects@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: p4 projects tree changes List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jul 2007 22:07:53 -0000 M. Warner Losh wrote: > In message: <200707152008.l6FK8Nr8028280@repoman.freebsd.org> > Garrett Cooper writes: > : http://perforce.freebsd.org/chv.cgi?CH=123550 > : > : Change 123550 by gcooper@optimus-revised_pkgtools on 2007/07/15 20:07:45 > : > : Quite simply, works with read, but not fread. Or maybe it's just me :)? > : > : Affected files ... > : > : .. //depot/projects/soc2007/revised_fbsd_pkgtools/usr/src/usr.sbin/pkg_install/lib/file.c#4 edit > : > : Differences ... > : > : ==== //depot/projects/soc2007/revised_fbsd_pkgtools/usr/src/usr.sbin/pkg_install/lib/file.c#4 (text+ko) ==== > : > : @@ -223,7 +223,7 @@ > : > : contents = (char *)malloc(sb.st_size + 1); > : > : - if ((int) fread(contents, sb.st_size, 1, fd) == FAIL) { > : + if (read(fileno(fd), contents, sb.st_size) == FAIL) { > : cleanup(0); > : errx(2, "%s: short read on '%s' - did not get %lld bytes", __func__, > : fname, (long long)sb.st_size); > > > The functions fread() and fwrite() advance the file position indicator > for the stream by the number of bytes read or written. They return the > number of objects read or written. If an error occurs, or the end-of- > file is reached, the return value is a short object count (or zero). > > vs > > If successful, the number of bytes actually read is returned. Upon read- > ing end-of-file, zero is returned. Otherwise, a -1 is returned and the > global variable errno is set to indicate the error. > > /me guesses FAIL is defined to be -1... > > Warner > Warner, Yes, FAIL is -1 according to . What I'm ultimately looking for is 0, for the EOF, since this is an attempt to prebuffer as many file lines as possible. Should I be doing additional file checking, i.e. file doesn't have EOF? I know it shouldn't happen with most file writes, but it could (or at least it does from time to time according to vim's status bar), and I want to avoid security risks and/or bugs.. As a sidenote, I was concerned about memory usage but it appears to be fairly minimal. I'll discuss it on relevant lists. Thanks! -Garrett