From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-return-24864-listarch-gdb=sources.redhat.com@sourceware.org>
Received: (qmail 17871 invoked by alias); 13 Apr 2006 08:02:29 -0000
Received: (qmail 17861 invoked by uid 22791); 13 Apr 2006 08:02:28 -0000
X-Spam-Check-By: sourceware.org
Received: from zigzag.lvk.cs.msu.su (HELO zigzag.lvk.cs.msu.su) (158.250.17.23)     by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 13 Apr 2006 08:02:26 +0000
Received: from Debian-exim by zigzag.lvk.cs.msu.su with spam-scanned (Exim 4.50) 	id 1FTwmS-0000Kt-Lx 	for gdb@sources.redhat.com; Thu, 13 Apr 2006 12:02:21 +0400
Received: from zigzag.lvk.cs.msu.su ([158.250.17.23]) 	by zigzag.lvk.cs.msu.su with esmtp (Exim 4.50) 	id 1FTwmB-0008TL-5e; Thu, 13 Apr 2006 12:02:03 +0400
From: Vladimir Prus <ghost@cs.msu.su>
To: Eli Zaretskii <eliz@gnu.org>
Subject: Re: printfs output in wrong order in MI
Date: Thu, 13 Apr 2006 08:20:00 -0000
User-Agent: KMail/1.7.2
Cc: gdb@sources.redhat.com
References: <e1j893$lse$1@sea.gmane.org> <e1kt1v$ssc$1@sea.gmane.org> <u1ww152q0.fsf@gnu.org>
In-Reply-To: <u1ww152q0.fsf@gnu.org>
MIME-Version: 1.0
Content-Type: text/plain;   charset="koi8-r"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200604131201.58613.ghost@cs.msu.su>
Mailing-List: contact gdb-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Subscribe: <mailto:gdb-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb/>
List-Post: <mailto:gdb@sourceware.org>
List-Help: <mailto:gdb-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: gdb-owner@sourceware.org
X-SW-Source: 2006-04/txt/msg00152.txt.bz2

On Thursday 13 April 2006 11:55, Eli Zaretskii wrote:

> > > Any ideas why "printf" is so special?
> >
> > I turns out that using
> >
> >   printf "%x\n", &i
> >
> > (that is, adding "\n"), fixes the problem. Still looks like a bug to me,
> > though.
>
> I think it's expected behavior: printf uses buffered output, 

Where in documentation is it stated that 'printf' uses buffered output?

> so if you 
> don't finish the line with a newline, the buffer is not flushed.
> Similar ``bugs'' can be seen in any C program that displays characters
> via printf without \n or fflush.

Isn't it possible to auto-flush the buffer at the end of "-interpreter-exec 
console" execution it's possible to flush the buffers? I think it's 
reasonable to expect that *all* output of command wrapped in 
"-interpreter-exec console" would appears before the "^done" marker.

- Volodya