> > 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? On Wed, Feb 10, 2016 at 5:05 PM, Joakim Sindholt wrote: > On Wed, 2016-02-10 at 16:49 -0500, Max Ruttenberg wrote: > > All, > > > > > > I guess my question is more easily asked through an example. If I have > > code that makes a call to puts and then a call to getchar, what > > mechanism enforces that stdout gets flushed before blocking for stdin? > > Is there a such a mechanism? My gut says yes but I haven't been able > > to pinpoint it. > > > > > > Thanks, > > Max > > 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. > > -- Max Ruttenberg, Member of the Technical Staff Emu *Technology* 1400 E Angela Blvd, Unit 101 South Bend, IN 46617