From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-patches-return-41769-listarch-gdb-patches=sources.redhat.com@sourceware.org>
Received: (qmail 24106 invoked by alias); 2 Dec 2005 01:23:35 -0000
Received: (qmail 24080 invoked by uid 22791); 2 Dec 2005 01:23:35 -0000
X-Spam-Check-By: sourceware.org
Received: from zproxy.gmail.com (HELO zproxy.gmail.com) (64.233.162.206)     by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 02 Dec 2005 01:23:30 +0000
Received: by zproxy.gmail.com with SMTP id l1so418807nzf         for <gdb-patches@sources.redhat.com>; Thu, 01 Dec 2005 17:23:28 -0800 (PST)
Received: by 10.36.127.10 with SMTP id z10mr2118079nzc;         Thu, 01 Dec 2005 17:23:28 -0800 (PST)
Received: by 10.37.2.6 with HTTP; Thu, 1 Dec 2005 17:23:28 -0800 (PST)
Message-ID: <8f2776cb0512011723s4b70d47dr6ffc0e2ff6ecaafb@mail.gmail.com>
Date: Fri, 02 Dec 2005 01:26:00 -0000
From: Jim Blandy <jimb@red-bean.com>
To: Nick Roberts <nickrob@snap.net.nz>
Subject: Re: [PATCH] Target stderr not displayed thru MI
Cc: Daniel Jacobowitz <drow@false.org>, Denis PILAT <denis.pilat@st.com>,  	gdb-patches@sources.redhat.com
In-Reply-To: <17295.22919.290876.649298@kahikatea.snap.net.nz>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <17293.36697.854192.691800@kahikatea.snap.net.nz> 	 <438DA1DE.2020406@st.com> 	 <17294.2894.345752.773239@kahikatea.snap.net.nz> 	 <438F011F.7050403@st.com> <20051201140436.GA31759@white> 	 <20051201143218.GB13069@nevyn.them.org> 	 <17295.22919.290876.649298@kahikatea.snap.net.nz>
X-IsSubscribed: yes
Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Subscribe: <mailto:gdb-patches-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb-patches/>
List-Post: <mailto:gdb-patches@sourceware.org>
List-Help: <mailto:gdb-patches-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: gdb-patches-owner@sourceware.org
X-SW-Source: 2005-12/txt/msg00032.txt.bz2

Adding a new MI output stream with its own magic character will break
existing MI clients.  I don't think that's worthwhile, especially
given that, when a program is talking to a TTY, you can't distinguish
the two either.

If, at some point in the future, the MI protocol does get extended to
distinguish the two streams, the code will be ready for it, since we
already distinguish gdb_stdtarg and gdb_stdtargerr internally.  This
change doesn't make future improvements difficult.