Mail Archives: djgpp-workers/1999/04/06/07:33:08
> > This returns 0, unless the fsync is turned on. Is this allowed and
> > intended this way?
> Yes.
I see.
> > 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.
But if the file is read again (via another handle) the operating system
knows what to do: read from the system buffers. No?
> > 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.
I understand. So it is Autoconf that is using unportable behaviour here. It
is in the check whether fflush(NULL) works.
> DJ, does Posix say anything about it?
> If not, I think this should be reported to Autoconf
> maintainers. They should call `fsync'.
Right.
> > 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.
I know. It's another problem.
> > f->_flag &= ~_IOUNGETC;
> > I assume this *can* have effect on an input stream.
> Yes. Please submit a change for the docs.
As soon as I have time again...
- Raw text -