From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14949 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: non-standard implementation of fflush() Date: Thu, 21 Nov 2019 14:04:44 -0500 Message-ID: <20191121190444.GE16318@brightrain.aerifal.cx> References: Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="118254"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "musl@lists.openwall.com" To: y38h5z@protonmail.com Original-X-From: musl-return-14965-gllmg-musl=m.gmane.org@lists.openwall.com Thu Nov 21 20:05:09 2019 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.89) (envelope-from ) id 1iXrlM-000Ueb-Vj for gllmg-musl@m.gmane.org; Thu, 21 Nov 2019 20:05:09 +0100 Original-Received: (qmail 22388 invoked by uid 550); 21 Nov 2019 19:05:06 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 22368 invoked from network); 21 Nov 2019 19:05:05 -0000 Content-Disposition: inline In-Reply-To: Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:14949 Archived-At: On Thu, Nov 21, 2019 at 06:31:02PM +0000, y38h5z@protonmail.com wrote: > Hello everyone, > > the implementation of fflush() in musl doesn't seem to conform to > the opengroup standard: > > https://pubs.opengroup.org/onlinepubs/009695399/functions/fflush.html > > In addition to flushing unwritten data, which is expected, musl > flushes the read buffer when calling fflush(). This leads to data > loss in bidirectional communication uses. Other standard libraries > don't do this. > > As a reference compare musl to openbsd's libc: > > https://git.musl-libc.org/cgit/musl/tree/src/stdio/fflush.c > https://github.com/openbsd/src/blob/master/lib/libc/stdio/fflush.c > > I think this is unexpected behavior and should be changed. ISO C leaves the behavior of fflush undefined unless "stream points to an output stream or an update stream in which the most recent operation was not input". POSIX further defines it for read, but only if the underlying fd is seekable: "For a stream open for reading with an underlying file description, if the file is not already at EOF, and the file is one capable of seeking, the file offset of the underlying open file description shall be set to the file position of the stream, and any characters pushed back onto the stream by ungetc() or ungetwc() that have not subsequently been read from the stream shall be discarded (without further changing the file offset). The case of reading from an unseekable stream is left undefined. Correct programs should not be doing this at all. The current behavior in musl is simply the default effect from not making any special provisions to treat unseekable streams differently, since there is not any particular behavior we're trying to achieve. Rich