From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-return-31036-listarch-gdb=sources.redhat.com@sourceware.org>
Received: (qmail 21481 invoked by alias); 12 Feb 2008 22:17:49 -0000
Received: (qmail 21471 invoked by uid 22791); 12 Feb 2008 22:17:48 -0000
X-Spam-Check-By: sourceware.org
Received: from bluesmobile.specifix.com (HELO bluesmobile.specifix.com) (216.129.118.140)     by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 12 Feb 2008 22:17:31 +0000
Received: from [127.0.0.1] (bluesmobile.specifix.com [216.129.118.140]) 	by bluesmobile.specifix.com (Postfix) with ESMTP id 232173B9F0; 	Tue, 12 Feb 2008 14:17:29 -0800 (PST)
Subject: Re: substitute gdb convenience variable into gdb command
From: Michael Snyder <msnyder@specifix.com>
To: Daniel Jacobowitz <drow@false.org>
Cc: Yakov Lerner <iler.ml@gmail.com>, gdb@sourceware.org
In-Reply-To: <20080212195544.GA27498@caradoc.them.org>
References: <f36b08ee0802120754r59b72f64vb9164965da338686@mail.gmail.com> 	 <1202845293.19253.97.camel@localhost.localdomain> 	 <20080212195544.GA27498@caradoc.them.org>
Content-Type: text/plain
Date: Tue, 12 Feb 2008 22:17:00 -0000
Message-Id: <1202854648.19253.107.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Evolution 2.10.3 (2.10.3-7.fc7)
Content-Transfer-Encoding: 7bit
X-IsSubscribed: yes
Mailing-List: contact gdb-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <gdb.sourceware.org>
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: 2008-02/txt/msg00082.txt.bz2

On Tue, 2008-02-12 at 14:55 -0500, Daniel Jacobowitz wrote:
> On Tue, Feb 12, 2008 at 11:41:33AM -0800, Michael Snyder wrote:
> > Hmm!  That's a bit of an oversight...
> > thread_apply_command calls strtol.  It ought to call
> > one of the built-in expression parsing functions.
> 
> Not really.  It would become pretty much impossible to parse the
> command if you did that.  There's no reliable way to find the end of
> an expression if it has unknown text afterwards.

You're right.  I ran into the same issue when I did the
dump and restore commands.  I used parse_and_eval_long, 
but only because I arranged the command syntax so that
the integer value was the last argument on the command line.

In this case it isn't the last argument, so we can't do that.