Eric Blake wrote on Thursday, December 04, 2008 1:42 AM::
> According to C-Programmer on 12/3/2008 6:29 PM:
>> But if I compile using the following command line argument:
>> $ gcc -mno-cygwin -o ioProg1 ioProg1.c
>
> Then you are no longer using cygwin, and this is almost more of a
> question for the mingw list.
>
>> I find that the DLL being used is msvcrt.dll and the program behaves
>> as if the gets( name ); line had come before the printf("What is
>> your name?"); line. Very strange!
>>
>> Any ideas on why this is happening?
>
> Yes. It's called buffering. Native Windows apps have no idea that
> cygwin emulates pty's with pipes, and blindly assume that all pipes
> are non-interactive. For performance reasons, when talking to a
> non-interactive client, all stdio libraries perform block buffering
> instead of line buffering when stdout is determined to be
> non-interactive. So, because you are running a native windows app in
> a cygwin console, your app doesn't realize that you wanted line
> buffering, and so you don't see output until 4k or end of process,
> even though the printf completed before the gets.
You beat me to it. I would only add that it is a mistake to rely on
the default buffering mode of stdio, particularly for interactive
programs. If you require a specific mode, you should always set it
using one of the functions setbuf, setbuffer, setlinebuf, or setvbuf.
In this case, you should call setlinebuf(stdout) to ensure that the
newline flushes the output.
If instead, you wanted the input to appear on the same line as the
prompt, you would need to call setbuf(stdout, 0) to force unbuffered
output.
Alternatively, you can just call fflush(stdout) before calling gets().
Phil
--
This email has been scanned by Ascribe PLC using Microsoft Antigen for Exchange.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
