[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 10 Feb 2016 18:39:01 -0500
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: Enforcing expected ordering of operations on stdout,
stdin, and stderr
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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
