Date: Thu, 10 Jun 2004 12:54:39 +1000 From: Tim Robbins <tim@robbins.dropbear.id.au> To: freebsd-arch@freebsd.org Subject: Re: fflush() on readonly files Message-ID: <20040610025439.GA11655@cat.robbins.dropbear.id.au> In-Reply-To: <20040610021356.GA4990@VARK.homeunix.com> References: <20040609154040.GA26229@asura.bsd> <20040610021356.GA4990@VARK.homeunix.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040610025439.GA11655>