From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id 0B1A3388A814 for ; Thu, 11 Jun 2020 03:07:06 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 0B1A3388A814 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=simark.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=simark@simark.ca Received: from [10.0.0.11] (173-246-6-90.qc.cable.ebox.net [173.246.6.90]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id BCA7B1E791; Wed, 10 Jun 2020 23:07:05 -0400 (EDT) Subject: Re: [RFAv6 1/3] default-args: allow to define default arguments for aliases To: Philippe Waroquiers , gdb-patches@sourceware.org References: <20200516171947.10507-1-philippe.waroquiers@skynet.be> <20200516171947.10507-2-philippe.waroquiers@skynet.be> <9419d28e-994d-ec6a-c202-098937c0198f@simark.ca> <03ebfe32742f6c66d168cbc7bbc18073a03d8e54.camel@skynet.be> <540c4499-a74c-85c2-6fea-473088ce3144@simark.ca> <08bfa843ce1e91f08cd843feb81e9e6e8124e35b.camel@skynet.be> From: Simon Marchi Message-ID: <84b5dab7-ca14-a513-fc3b-fb7effcf79fb@simark.ca> Date: Wed, 10 Jun 2020 23:07:05 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <08bfa843ce1e91f08cd843feb81e9e6e8124e35b.camel@skynet.be> Content-Type: text/plain; charset=utf-8 Content-Language: fr Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.6 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2020 03:07:07 -0000 On 2020-06-10 2:56 p.m., Philippe Waroquiers wrote: > On Tue, 2020-06-09 at 18:59 -0400, Simon Marchi wrote: >> >> I understand that this is because of the current implementation, but I really >> think that the behavior is unexpected from the point of view of the user. If >> default arguments don't add up when defining an alias based on another alias, >> then I'd suggest preventing the user from creating aliases based on other >> aliases. The rationale being that there is no point in doing: >> >> (gdb) alias aaa = print abc >> (gdb) alias bbb = aaa def >> >> over >> >> (gdb) alias aaa = print abc >> (gdb) alias bbb = print def >> >> And the former would just cause confusion with the current behavior (even if >> documented in the manual). Plus, if we allow the former, we will be stuck with >> this behavior, we won't be able to change it in the future if we want to >> implement the behavior where the default arguments accumulate. >> >> I have to admit that I didn't dig much in the implementation, but this is how I >> would see it. Right now, when you define `bbb`, bbb's cmd_list_element->cmd_pointer >> points to print's cmd_list_element. Would it be hard to make it point to aaa's >> cmd_list_element instead? This way, when we look up command `bbb`, we could resolve >> the aliases recursively (or iteratively) and just build up the default args string >> as each alias level is resolved. If we take the example from above, when executing >> command `bbb`, we would end up with default args "abc def". > Yes, to expand the args, we would have to scan a linked list of aliases. > the linked list should replace the current pointer to the aliased command. > But as far as I can see, there are a bunch of other things to rework > (such as the chain of alias of a command). > So, not a minor change (as you presume below). >> >> I presume it's doable but not a simple change, so that's why I suggest for now to >> just prevent defining aliases based on aliases, so we can keep the door open to >> implementing it later. > Yes, that is a good idea. > > I will implement this protection/prevention this week-end. > Note that to avoid having a backward incompatible change, I suggest to report an > error only when the new or the old alias have default args. > Otherwise, we will break .gdbinit of users that have done: > alias aaa = backtrace > alias bbb = aaa Ah right, the alias command already exists so this is an existing use case. That's fine with me, since that will continue to work without change in behavior the day we implement the default arg with aliases thing. Simon