Re: fflush() on readonly files

From: Tim Robbins (tim_at_robbins.dropbear.id.au)
Date: 06/10/04

  • Next message: Bruce Evans: "Re: dev_t / udev_t confusion ?" 
    Date: Thu, 10 Jun 2004 12:54:39 +1000
To: freebsd-arch@freebsd.org

    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
    _______________________________________________
    freebsd-arch@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-arch
    To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"

  • Next message: Bruce Evans: "Re: dev_t / udev_t confusion ?"

    Relevant Pages

    • fflush() on readonly files
      ... which makes fflushon read only descriptors do not return error code. ... Reasons for this patch: ... - Makes fflush() and fsyncbehavior identical - avoids programmer's confusion. ... Are there any other reasons for non commiting it? ...
      (freebsd-arch)
    • Re: fflush() on readonly files
      ... > which makes fflush() on read only descriptors do not return error code. ... > Reasons for this patch: ...
      (freebsd-arch)
    • Re: scanf() quesion?
      ... Please not that msdn describes the behaviour of one particular compiler ... With fflush() for example, Microsoft has chosen to provide ... a.c.l.l.c-c++ FAQ: http://www.comeaucomputing.com/learn/faq ...
      (comp.lang.c)