From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 117840 invoked by alias); 28 Aug 2018 23:29:55 -0000 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 Received: (qmail 117830 invoked by uid 89); 28 Aug 2018 23:29:54 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.9 required=5.0 tests=AWL,BAYES_00,KAM_ASCII_DIVIDERS,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=no version=3.3.2 spammy=proposing X-HELO: mail-wr1-f65.google.com Received: from mail-wr1-f65.google.com (HELO mail-wr1-f65.google.com) (209.85.221.65) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 28 Aug 2018 23:29:53 +0000 Received: by mail-wr1-f65.google.com with SMTP id g33-v6so3054928wrd.1 for ; Tue, 28 Aug 2018 16:29:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=embecosm.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=sWXIumHU7FZvHXjqj6JfAnCnsu3Nl9tCFom+JAng//Q=; b=XHI+vH8F5BNphvxHkaB+WXWsyeT4tzw/dLKZE+6CcPeWhQVobbZYqG2BR2xLI1x05H uXIyvNTgfjzQJbr9netd7OUKHh3NhkxuwXeUEv2QoolWxGJ1i5O5Zl0zvGDVAYytLrf+ 3IhfGRhJ0Etu37d+idu/KDbcWk+wHVehjfJOAgT/8ATRpW3K+PgoVgkJm0sXTUMoT2w+ fSX5uL+IKeipSOhLlS8oEpua9//LrWUl0qnmDeLMgqUOXH/Or9Z3nCnwPCAoRx5xNd6P f4lxWYQvS+8dN2at0SfZWvwqMhOz4a2o0ttGIvHcFGfJ1hry6mOkuBJke0shqBjBO8Gu xDUg== Return-Path: Received: from localhost (host86-134-20-86.range86-134.btcentralplus.com. [86.134.20.86]) by smtp.gmail.com with ESMTPSA id a6-v6sm3477138wmf.22.2018.08.28.16.29.49 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 28 Aug 2018 16:29:49 -0700 (PDT) Date: Tue, 28 Aug 2018 23:29:00 -0000 From: Andrew Burgess To: Philippe Waroquiers Cc: Tom Tromey , gdb-patches@sourceware.org Subject: Re: [PATCH 2/2] gdb: Allow parenthesis to group arguments to user-defined commands Message-ID: <20180828232948.GK32506@embecosm.com> References: <1535225533.1438.5.camel@skynet.be> <1535230403.1438.10.camel@skynet.be> <20180825224310.GA32506@embecosm.com> <87lg8q7ai7.fsf@tromey.com> <20180828184331.GJ32506@embecosm.com> <1535488137.7778.4.camel@skynet.be> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <1535488137.7778.4.camel@skynet.be> X-Fortune: Are you making all this up as you go along? X-Editor: GNU Emacs [ http://www.gnu.org/software/emacs ] User-Agent: Mutt/1.9.2 (2017-12-15) X-IsSubscribed: yes X-SW-Source: 2018-08/txt/msg00719.txt.bz2 * Philippe Waroquiers [2018-08-28 22:28:57 = +0200]: > On Tue, 2018-08-28 at 19:43 +0100, Andrew Burgess wrote: > > * Tom Tromey [2018-08-28 09:53:52 -0600]: > >=20 > > > > > > > > "Andrew" =3D=3D Andrew Burgess writes: > > >=20 > > > Andrew> So, my suggestion deliberately avoids using quotes or backsla= shes as > > > Andrew> these are bogged down in the existing code. And using (...) = is fairly > > > Andrew> intuitive given GDBs C like expression handling, personally I= 'd rather > > > Andrew> write: > > > Andrew> my_command ({unsigned long long} &global_var) > > > Andrew> than: > > > Andrew> my_command {unsigned\ long\ long}\ &global_var > > >=20 > > > FWIW I tend to agree with your logic here. > > >=20 > > > User-defined argument parsing is broken (and I think there's at least > > > one bug in bugzilla about this), but at the same time, making breaking > > > changes seems unfriendly. Your approach doesn't seem to be breaking > > > anything that is likely to be actually used. >=20 > I do not think a \ followed by a space will create a lot of incompatibili= ties. > i > .e. that someone would type > some_user_defined_command a\ b > to give 2 > different args to the command. No, and what they get at the moment is a single argument, which is: a\ b including the backslash and the space. Is this correct, or useful? I suspect not, but my instinct in these cases is not to mess with things without good reason, and I didn't have a good reason. >=20 > For single quotes: it is unlikely that someone types something like > some_user_defined_command 'abc def' > and was expecting the user defined command to receive two args. I agree, and what they get right now is: 'abc def' including the quotes. > What is however a lot more likely is > some_user_defined_command 'a' > and this command expects to receive a character value. Which is more or less what you get: 'a' > So, yes, single quotes has more potential to create > incompatibilities. I guess that depends on what you're proposing the argument should evaluate too. >=20 > On the downside, quoting with parenthesis is something very peculiar > (is there some other tool/shell/... using this convention ?). I guess I never saw it as quoting, just grouping an expression together. I think I see GDB as mostly consuming C like expressions, which is why using () seemed natural enough. Coincidentally the users I'm working with initially tried () too (without prompting from me) so my focus group of 2 all agreed with me ;-) >=20 > And from a previous discussion with Pedro, he indicated that > some commands in gdb already are using single quotes. > The 'Not sure' below is a quote of Pedro :), replying to a suggestion > I gave to let the user tell explicitly if an arg was quoted or not. > >=A0=A0=A0* have a way to (explicitely) quote an argument e.g. > >=A0=A0=A0=A0=A0=A0=A0info var=A0=A0-Qt 'long int'=A0=A0regexpofsomeva= rs > >=A0=A0=A0=A0=A0where -Q indicates that the next "value argument" is > >=A0=A0=A0=A0=A0explicitely quoted. >=20 > Not sure we need that -Q.=A0=A0We can support optional quotes, and > tell users to add quotes if necessary?=A0=A0That's what we've done > since forever in linespecs and expressions, for example. >=20 > It is based on this that I used single quotes in the=A0 > info var/func/arg/local -t TYPEREGEXP NAMEREGEXP > patch. >=20 > > Given that the argument passing for user-defined functions is pretty > > self contained we could, conceivably, implement a whole new system and > > have a switch to select between them... the existing code does seem > > rather odd. > >=20 > > But ideally, I'd like that to be a project for another day. > And we also have the 'generalised arg parser' prototype that Pedro has > in a corner. >=20 > IMO, clearly, what to do is unclear :). I agree, except I need to figure out some clarity in order to resolve the real issue I have :) I think that you're arguing in favour of reworking the argument passing to user-defined commands. I'm not entirely sure exactly what rules you're proposing we adopt though. Maybe you could help me work through a few examples, in the following table I've outlined a few examples, and have the following questions: [1] What argument(s) would be passed under the new scheme? [2] What argument(s) would be passed under the new scheme? [3] How would I write {unsigned long} &var to pass this as a single argument? If with quotes, how does this relate to 1 & 2? | Input | Current Arguments(s) | Proposed Argument(s) | |----------------------+----------------------+----------------------| | a b | a | a | | | b | b | |----------------------+----------------------+----------------------| | "a b" | "a b" | [1] | |----------------------+----------------------+----------------------| | 'a b' | 'a b' | [2] | |----------------------+----------------------+----------------------| | {unsigned long} &var | {unsigned | | | | long} | N/A | | | &var | | |----------------------+----------------------+----------------------| | [3] | | | |----------------------+----------------------+----------------------| In general I'm happy to rework this part of GDB, but ideally I'd like some feedback from a global maintainer that such a change, which might would break backward compatibility, would be acceptable... Thanks, Andrew