From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-return-24405-listarch-gdb=sources.redhat.com@sourceware.org>
Received: (qmail 15428 invoked by alias); 20 Feb 2006 07:25:16 -0000
Received: (qmail 15413 invoked by uid 22791); 20 Feb 2006 07:25:15 -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; Mon, 20 Feb 2006 07:25:11 +0000
Received: from Debian-exim by zigzag.lvk.cs.msu.su with spam-scanned (Exim 4.50) 	id 1FB5Pw-0006sb-0H 	for gdb@sources.redhat.com; Mon, 20 Feb 2006 10:25:08 +0300
Received: from zigzag.lvk.cs.msu.su ([158.250.17.23]) 	by zigzag.lvk.cs.msu.su with esmtp (Exim 4.50) 	id 1FB5Nz-0006qr-00; Mon, 20 Feb 2006 10:23:07 +0300
From: Vladimir Prus <ghost@cs.msu.su>
To: Bob Rossi <bob@brasko.net>
Subject: Re: MI: type prefixes for values
Date: Mon, 20 Feb 2006 07:28:00 -0000
User-Agent: KMail/1.7.2
Cc: Eli Zaretskii <eliz@gnu.org>,  gdb@sources.redhat.com
References: <dt43qh$sns$1@sea.gmane.org> <uoe15hjnt.fsf@gnu.org> <20060217193558.GD14873@brasko.net>
In-Reply-To: <20060217193558.GD14873@brasko.net>
MIME-Version: 1.0
Content-Type: text/plain;   charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200602201023.05756.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-02/txt/msg00265.txt.bz2

On Friday 17 February 2006 22:35, Bob Rossi wrote:

> Vladimir, stop trying to parse fields that are unparsable by nature. If
> you want to parse the data, your on your own. If you submit a patch that
> makes GDB output data in more atomic pieces, I think everyone would be
> OK with that.

We're running in circles. I've asked about possible patch, but instead got 
lengthy replies about how parsing value field is bad idea. To repeat -- I 
started this thread because *I* want to avoid parsing that field.

To make an even more specific question, I propose to:

   - Remove type prefix from output of -data-evaluate-expression and
        -var-evaluat-expression
   
   - Add 'type' field to the output of -data-evaluate-expression


Is this OK with everyone?

- Volodya