Date: Tue, 6 Apr 1999 12:53:26 +0200 (IST) From: Eli Zaretskii X-Sender: eliz AT is To: Michel de Ruiter cc: "'DJGPP workers'" Subject: Re: fflush question In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Precedence: bulk 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.