Date:	Tue, 6 Apr 1999 12:53:26 +0200 (IST)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	Michel de Ruiter <Michel AT smr DOT nl>
cc:	"'DJGPP workers'" <djgpp-workers AT delorie DOT com>
Subject:	Re: fflush question
In-Reply-To:	<B0FEA00E82A7D1118BFB00A0CC990278213234@ARGON>
Message-ID:	<Pine.SUN.3.91.990406124136.16726L-100000@is>
MIME-Version:	1.0
Reply-To:	djgpp-workers AT delorie DOT com
X-Mailing-List:	djgpp-workers AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

On Tue, 6 Apr 1999, Michel de Ruiter wrote:

> This returns 0, unless the fsync is turned on. Is this allowed and
> intended this way?

Yes.

> The ANSI C9x draft (January 18, 7.19.5.2, page 306)
> says about fflush's functionality in this case:
> 
>      ... the fflush function causes any unwritten data ... to be
>      delivered to the host environment to be written to the file ...

If this is interpreted like you seem to suggest, then why does Unix need 
the `fsync' system call?  Obviously, `fflush' doesn't deliver the data to 
the disk, but to the system buffers (aka disk cache), which then write
the data at its discretion.

> I cannot find anything about one file being open as two streams (input
> and output) simultaneously, except (7.19.3, page 301):

The test program opens the file on ANOTHER HANDLE, and assumes the data 
will be available.  IMHO, this is non-portable.  This is DOS that 
interferes here, we cannot do anything to correct it.

DJ, does Posix say anything about it?

If not, I think this should be reported to Autoconf maintainers.  They 
should call `fsync'.

> Oh, now we are at it, ANSI C9x (Annex J.2, page 557) says trying to
> fflush an input stream causes undefined behaviour

I don't see how this is relevant, since the code you posted fflush'ed an 
output stream, not an input stream.

>     f->_flag &= ~_IOUNGETC;
> 
> I assume this *can* have effect on an input stream. 

Yes.  Please submit a change for the docs.

- Raw text -