X-Recipient: archive-cygwin AT delorie DOT com
X-Spam-Check-By: sourceware.org
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; 	charset="US-ASCII"
Subject: RE: Using -mno-cygwin causes different program behavior
Date: Thu, 4 Dec 2008 02:16:37 -0000
Message-ID: <5E25AF06EFB9EA4A87C19BC98F5C87530208CC19@core-email.int.ascribe.com>
In-Reply-To: <49373554.6000507@byu.net>
References: <20825507 DOT post AT talk DOT nabble DOT com> <49373554 DOT 6000507 AT byu DOT net>
From: "Phil Betts" <Phil DOT Betts AT ascribe DOT com>
To: <cygwin AT cygwin DOT com>
X-IsSubscribed: yes
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
List-Id: <cygwin.cygwin.com>
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id mB42HHsc010493

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/