From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31319 invoked by alias); 10 Dec 2008 15:32:53 -0000 Received: (qmail 31307 invoked by uid 22791); 10 Dec 2008 15:32:51 -0000 X-Spam-Check-By: sourceware.org Received: from eu1sys200aog120.obsmtp.com (HELO eu1sys200aog120.obsmtp.com) (207.126.144.149) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 10 Dec 2008 15:32:00 +0000 Received: from source ([164.129.1.35]) (using TLSv1) by eu1sys200aob120.postini.com ([207.126.147.11]) with SMTP ID DSNKST/g5gMvFQ1O6QZ8dSB/XWP2HQsNGPe1@postini.com; Wed, 10 Dec 2008 15:32:00 UTC Received: from zeta.dmz-eu.st.com (ns2.st.com [164.129.230.9]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 2DA72DA4D; Wed, 10 Dec 2008 15:31:42 +0000 (GMT) Received: from mail1.cro.st.com (mail1.cro.st.com [164.129.40.131]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 2ED664C490; Wed, 10 Dec 2008 15:31:49 +0000 (GMT) Received: from crx595.cro.st.com (crx595.cro.st.com [164.129.44.95]) by mail1.cro.st.com (MOS 3.8.7a) with ESMTP id CQW92665 (AUTH "denis pilat"); Wed, 10 Dec 2008 16:32:01 +0100 (CET) Message-ID: <493FE0E4.7080105@st.com> Date: Wed, 10 Dec 2008 15:32:00 -0000 From: Denis PILAT User-Agent: Thunderbird 2.0.0.18 (X11/20081105) MIME-Version: 1.0 To: Doug Evans , Michael Snyder , Jon Beniston , "gdb-patches@sourceware.org" Cc: Denis PILAT Subject: Re: Patch to support spaces in filenames & paths References: <7D653316E38B4305941199D722BF20B0@bibi> <4935A5E2.5050503@vmware.com> <20081202233738.GA15530@caradoc.them.org> <4937A4E3.4040609@st.com> <20081204131028.GA24868@caradoc.them.org> In-Reply-To: <20081204131028.GA24868@caradoc.them.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-12/txt/msg00187.txt.bz2 I made some experiments with parse_to_comma_and_eval, but I think I must be sure to understand what you need before going further in my implementation, and summarize the situation My original proposal (http://sourceware.org/ml/gdb-patches/2008-12/msg00029.html) allows spaces in dump/restore/append command arguments, having the constraint for user to quote its arguments that contains spaces, but that doesn't break actual gdb behavior. Then Doug said While perhaps not applicable in Denis' case (since the command accepts "a b c" instead of "a, b, c" (though I wonder if it could accept both), for completeness' sake there is also parse_to_comma_and_eval. In the current implementation, space is considered as a separator for all arguments, except for the last that can contains any spaces and will be evaluated entirely. Accepting "a, b, c" as 3 argument consists in making comma the separator for arguments, and that will break existing front-ends, it's an API change. The patch I have proposed accepts "a, b, c" but considers it's a single argument, like it could be for any expression with coma (ie "max(a, b)"). Please enlighten me on what kind of syntax you'd like dump/restore/append to accept, knowing that a, b and c could also be complex expressions with comma and spaces as well. Thanks for your feedback -- Denis Daniel Jacobowitz wrote: > On Thu, Dec 04, 2008 at 10:37:39AM +0100, Denis PILAT wrote: > >> Actual implementation of append/dump/restore does not accept spaces at >> all, except in the last argument, and I think it's just a side effect. >> To me comma must not be considered as a separator since dump command >> accepts expression and the calculation of START , END address or OFFSET >> is often a function call like sizeof (), but can be more than that like a >> function that takes more than one parameters, "max(a,b)" or whatever. >> > > I don't think it applies here, but take a peek at the function Doug > mentioned - it does handle nested commas. It's not perfect, but it's > pretty good. > >