From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/9302 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Enforcing expected ordering of operations on stdout, stdin, and stderr Date: Wed, 10 Feb 2016 18:39:01 -0500 Message-ID: <20160210233900.GG9349@brightrain.aerifal.cx> References: <1455141901.26335.95.camel@zhasha.com> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1455147558 11848 80.91.229.3 (10 Feb 2016 23:39:18 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 10 Feb 2016 23:39:18 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-9315-gllmg-musl=m.gmane.org@lists.openwall.com Thu Feb 11 00:39:17 2016 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1aTeLt-00071t-CK for gllmg-musl@m.gmane.org; Thu, 11 Feb 2016 00:39:17 +0100 Original-Received: (qmail 32657 invoked by uid 550); 10 Feb 2016 23:39:15 -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 32634 invoked from network); 10 Feb 2016 23:39:14 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:9302 Archived-At: On Wed, Feb 10, 2016 at 06:08:47PM -0500, Max Ruttenberg wrote: > > > > fflush(stdout); > > This is more of a basic C thing than a libc ml thing. You should > > consider picking up a copy of The C Programming Language by Kernighan > > and Ritchie. It will explain all of this. > > > I know about fflush, thanks. > > Consider this program: > > int main() > { > char buff[2]; > puts("enter a character"); > buff[0] = getchar(); > buff[1] = '\0'; > puts(buff); > return 0; > } > > If I compile that on linux-amd64, with or without musl, I will see "enter a > character" printed to my console and then be prompted for a character, as > opposed to the other way around. I don't know if this is formally > guaranteed by the C standard, but somehow that order seems to be > maintained. > > But if I grep the source code in musl/src/stdio for "fflush" I don't see a > bunch of calls to fflush. I see a call to it in fclose and freopen... but > that's neither surprising nor helpful. If I do the same in > musl/src/internal I also don't get anything. I've even tried just greping > for "flush." > > And yet somehow the order is maintained within those calls to puts and > getchar. So what I'm asking is: how? What part of the internal musl source > even attempts to enforce that ordering? I know the calling application can > do it with calls to fflush, but somehow that doesn't seem to be necessary > short of a signal interrupting the expected flow of execution. Am I just > getting lucky 100% of the time or is there some source in the stdio library > that's enforcing this? When attached to a terminal ("interactive device" in the terminology of the C standard), stdout is line-buffered by default. This means that writing a newline, which puts() inherently does at the end of its output, causes output to be flushed. The code path from puts.c is via the macro form of putc_unlocked, which is defined in src/internal/stdio_impl.h, and bypasses the fast write-to-buffer code path when c==f->lbf (f->lbf is set to '\n' for line-buffered mode, -1 for other modes). Actually even if stdout were not a terminal you would _happen_ to see this behavior on musl because whether stdout is line-buffered is decided lazily at the first encounter of '\n', so the "first line of output" is always line-buffered. But this is an implementation detail and not something you should rely on. If you want line-buffered behavior even for non-interactive stdout, you need to call setvbuf (as the first action on the file). Also, ISO C permitted and even encouraged (but made optional) a behavior whereby attempting to read from a line-buffered input stream causes all line-buffered output streams to be flushed. While this is convenient for programmers who write prompt strings not ending in newlines, and who don't want to be bothered with calling fflush, this feature was conceived in an era where C did not have multi-threading, and providing it when you have threads imposes a heavy synchronization burden and can even lead to deadlock. Therefore musl does not do it. So if you want to print prompt strings that don't end in a newline, and have them appear before input is read, you have to use fflush yourself. Does this help? Rich