Date: Tue, 6 Apr 1999 11:06:54 -0400
Message-Id: <199904061506.LAA08778@envy.delorie.com>
From: DJ Delorie <dj AT delorie DOT com>
To: djgpp-workers AT delorie DOT com
In-reply-to: <B0FEA00E82A7D1118BFB00A0CC990278213234@ARGON> (message from
	Michel de Ruiter on Tue, 6 Apr 1999 11:26:21 +0200)
Subject: Re: fflush question
References:  <B0FEA00E82A7D1118BFB00A0CC990278213234 AT ARGON>
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


>   fflush(fpw);
>   /*fsync(fileno(fpw));*/

I suspect this is a "bug" in dos, but that most unix programs that
care would expect it to work without fsync.  If calling fsync is what
we need to do to make fflush work like unix, I have no problem adding
it.

> Oh, now we are at it, ANSI C9x (Annex J.2, page 557) says trying to
> fflush an input stream causes undefined behaviour, "with or without
> the issuance of a diagnostic message". Maybe we should consider
> generating some warning?

I don't like silent failures; they generate FAQs.  I'd prefer we
either print a warning or make it work the way people "expect" it to
work.

> But fflush.c nevertheless does:
> 
>     f->_flag &= ~_IOUNGETC;
> 
> I assume this *can* have effect on an input stream. Which behaviour is
> intented?

If it's not going to do anything, it should do nothing.  We currently
don't have any specific checks for read streams, so you get the
"undefined" behavior (I think my todo mbox has a patch to change
this).