[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAD+Cw=fWmTr9eOokk9EjOW-SbZKHJ71t5Ox7px2DQt5FQcZTbQ@mail.gmail.com>
Date: Wed, 10 Feb 2016 20:17:12 -0500
From: Max Ruttenberg <mruttenberg@...technology.com>
To: musl@...ts.openwall.com
Subject: Re: Enforcing expected ordering of operations on stdout,
stdin, and stderr
Rich,
Thank you, that last email was very helpful. I see now that if I swap
printf for that first puts and don't include a newline character I get
prompted for input before the message the appears.
Thanks so much,
Max
On Wed, Feb 10, 2016 at 6:39 PM, Rich Felker <dalias@...c.org> wrote:
> 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
>
--
Max Ruttenberg,
Member of the Technical Staff
Emu *Technology*
1400 E Angela Blvd, Unit 101
South Bend, IN 46617
Content of type "text/html" skipped
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.
