From owner-freebsd-arch@FreeBSD.ORG Thu Jun 10 02:53:13 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BA65316A4CE for ; Thu, 10 Jun 2004 02:53:13 +0000 (GMT) Received: from smtp01.syd.iprimus.net.au (smtp01.syd.iprimus.net.au [210.50.30.52]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0053043D31 for ; Thu, 10 Jun 2004 02:53:13 +0000 (GMT) (envelope-from tim@robbins.dropbear.id.au) Received: from robbins.dropbear.id.au (210.50.216.230) by smtp01.syd.iprimus.net.au (7.0.024) id 40B7A0DA0038665D for freebsd-arch@freebsd.org; Thu, 10 Jun 2004 12:53:12 +1000 Received: by robbins.dropbear.id.au (Postfix, from userid 1000) id CAEF341F4; Thu, 10 Jun 2004 12:54:39 +1000 (EST) Date: Thu, 10 Jun 2004 12:54:39 +1000 From: Tim Robbins To: freebsd-arch@freebsd.org Message-ID: <20040610025439.GA11655@cat.robbins.dropbear.id.au> References: <20040609154040.GA26229@asura.bsd> <20040610021356.GA4990@VARK.homeunix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040610021356.GA4990@VARK.homeunix.com> User-Agent: Mutt/1.4.1i Subject: Re: fflush() on readonly files X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2004 02:53:13 -0000 On Wed, Jun 09, 2004 at 07:13:56PM -0700, David Schultz wrote: > On Wed, Jun 09, 2004, Radim Kolar wrote: > > I have submitted pr http://www.freebsd.org/cgi/query-pr.cgi?pr=65402 with patch > > which makes fflush() on read only descriptors do not return error code. > > > > Reasons for this patch: > > 1 - Do not breaks ISO C standard > > 2 - Makes FreeBSD undefined behavior compatible with other operation systems > > 3 - Correct some programs depending on this > > Are there any such programs? > > > 4 - Makes fflush() and fsync() behavior identical - avoids programmer's confusion. > > 5 - If there are no data to flush() then flush operation (dummy) succeeds, not failed. > > > > Against this patch: > > Programs which rely upon fflush() not returning an error > > when passed a file which is opened read-only are broken, > > and should be fixed. > > > > Colin Percival > > I don't see how that's an argument against it. Programs that call > fflush() on a read-only stream are broken either way. > > > Are there any other reasons for non commiting it? I think that in this case > > pro > cons. > > Well, I think all those other operating systems (Solaris, HP-UX, > Linux, etc.) are wrong in this case, but it would probably behoove > us to conform to the /de facto/ standard. This patch has already been discussed, and I thought it was pretty obvious that it had been rejected. The behaviour of fflush() on a read-only stream is not defined by any relevant standards, and there is no consensus on what it should do. It is a no-op on 7th edition UNIX (this may have just been to simplify implementing the other functions; rewind() calls fflush() regardless of mode.) It discards unread buffered data (like fpurge()) in the Microsoft C library. I think other MS-DOS and Windows libraries behaved similarly to Microsoft's. In my experience, fflush() is only called on input streams when the Microsoft behaviour is expected. Some people are taught to write C like this: int j; scanf("%d", &j); fflush(stdin); /* ... more scanf() calls ... */ ... which is wrong, and silently does something other than what the programmer expected on many systems. Bottom line: learn C, fix your code. Tim