printf before scanf doesn't show printf string before input

[GoogleCodeExporter]

What steps will reproduce the problem?

#include <stdio.h>

int main(int argc, char* argv[]){
    int n;
    printf("Please input a number\n");
    scanf("%d", &n);
    printf("The number is %d\n", n);
    return 0;
}

What is the expected output? What do you see instead?

I expected see
Please input a number
88(input number here)
The number is 88

but I see
88(input number here)
Please input a number
The number is 88

What versions of mintty, Cygwin/MSYS, and Windows are you using?
mintty svn-0.8.3-r1013(release by Mingw)  msys windows7

Please provide any additional information below.

Original issue reported on code.google.com by Squall...@gmail.com on 12 Sep 2010 at 9:40

• Merged into: #56

Attachments:

• err.png
• r.png
• test.c

[GoogleCodeExporter]

I'm afraid this is yet another instance of issue 56.

Mintty is based on Cygwin/MSYS pseudo terminal devices (ptys), which are 
implemented using Windows pipes. This means that in a MinGW-compiled program 
running in mintty, stdout will be a pipe.

The key to the problem is that stdout's default buffering mode depends on the 
type of device: unbuffered for a console, buffered for a pipe. This means that 
in a console the output will appear immediately, whereas in mintty it will only 
appear once the buffer is either full or flushed, as happens at the end of 
main().

Hence there are two ways to work around this: call fflush(stdout) whenever 
output needs to appear, or switch stdout to unbuffered mode at the start of the 
program, like so:

  setvbuf(stdout, 0, _IONBF, 0);

Switching it to line buffering, e.g. with setvbuf(stdout, 0, _IOLBF, BUFSIZ), 
ought to work too, but apparently with MinGW that has the same effect as 
enabling full buffering, because it causes your test to fail in the console too.

The issue appears in other programs that redirect stdio via pipes too, e.g. 
Eclipse: https://bugs.eclipse.org/bugs/show_bug.cgi?id=199219.

Programs built with the Cygwin or MSYS compilers are not affected by this.

Original comment by andy.koppe on 12 Sep 2010 at 4:50

• Changed state: Duplicate