From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11797 invoked by alias); 13 Dec 2004 19:55:37 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 11575 invoked from network); 13 Dec 2004 19:55:19 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 13 Dec 2004 19:55:19 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id iBDJtEqk002513; Mon, 13 Dec 2004 14:55:14 -0500 Received: from pobox.toronto.redhat.com (pobox.toronto.redhat.com [172.16.14.4]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id iBDJtEr04623; Mon, 13 Dec 2004 14:55:14 -0500 Received: from touchme.toronto.redhat.com (IDENT:postfix@touchme.toronto.redhat.com [172.16.14.9]) by pobox.toronto.redhat.com (8.12.8/8.12.8) with ESMTP id iBDJtCoS007130; Mon, 13 Dec 2004 14:55:13 -0500 Received: from redhat.com (toocool.toronto.redhat.com [172.16.14.72]) by touchme.toronto.redhat.com (Postfix) with ESMTP id 2C35B8002A2; Mon, 13 Dec 2004 14:55:12 -0500 (EST) Message-ID: <41BDF3A0.6020909@redhat.com> Date: Mon, 13 Dec 2004 19:55:00 -0000 From: Jeff Johnston User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 MIME-Version: 1.0 To: Peter Astrand Cc: cygwin@cygwin.com, newlib@sources.redhat.com Subject: Re: short fread(), but no ferror/feof References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-12/txt/msg00444.txt.bz2 Peter Astrand wrote: > Dave Korn wrote: > > >> The fix and the problem Peter is seeing are orthogonal. >> >> The fix referred to above fixes this problem: >> >>http://sources.redhat.com/ml/newlib/2004/msg00478.html >>"Hence, one can see that fread() in unbuffered mode always returns the >>specified count instead of the number of elements actually read." >> >> That is why, as Peter has observed, fread() returns the number of >>elements >>actually read. Without the patch, it would have been returning the entire >>number requested, which would have been even wronger. > > > Ah, thanks for clarifying this. > > > >> However Peter's problem is that when fread() does a partial read, it doesn't >>set either the EOF mark or the error indication on the file stream. A strict >>reading of the fread() specification suggests that it should have set one of >>those. > > > IMO, there's no room for intepretation in this situation: As I stated > in my original post, IEEE Std 1003.1 is very clear: > > "fread() shall return the number of elements successfully read which is > less than nitems only if a read error or end-of-file is encountered." > Where in the POSIX standard did you find that above line? I could not locate it in mine. The line above is in SUSV3. ANSI and C99 are more relaxed and simply state that the number of elements returned may be less than asked if EOF or an error has occurred. Regardless, the behavior is wrong. The same test on a buffered file yields the EOF. I have posted a patch. -- Jeff J. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/