From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 105191 invoked by alias); 24 Sep 2018 13:07:36 -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 105164 invoked by uid 89); 24 Sep 2018 13:07:36 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=dates, that, H*i:sk:1537733, hasn't X-HELO: gateway30.websitewelcome.com Received: from gateway30.websitewelcome.com (HELO gateway30.websitewelcome.com) (50.116.125.1) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 24 Sep 2018 13:07:34 +0000 Received: from cm16.websitewelcome.com (cm16.websitewelcome.com [100.42.49.19]) by gateway30.websitewelcome.com (Postfix) with ESMTP id A8ABC579F2 for ; Mon, 24 Sep 2018 08:07:32 -0500 (CDT) Received: from box5379.bluehost.com ([162.241.216.53]) by cmsmtp with SMTP id 4QaEgIzDwaSey4QaIgi87X; Mon, 24 Sep 2018 08:07:32 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tromey.com; s=default; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=AQVLs+rpDZ0WXSRsHJdCetKbni6o/9u4nW+lIy0v7Ls=; b=GAsUnFnCLYWNpIQGl6a2zhIilo 23IuuBdtOx84xORlh1MLpMP+nN2D2WbKkVXroTOAwJbWgByfD7uMBCSDwwvS1rpCt8ynmfYH9LTlc 6McSZYB0RKC1PVyS5p+3EK3R2; Received: from 97-122-190-66.hlrn.qwest.net ([97.122.190.66]:40298 helo=pokyo) by box5379.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1g4QaE-000d10-Hg; Mon, 24 Sep 2018 08:07:26 -0500 From: Tom Tromey To: Philippe Waroquiers Cc: Tom Tromey , gdb-patches@sourceware.org Subject: Re: [RFAv2 1/6] New cli-utils.h/.c function extract_info_print_args References: <20180826165359.1600-1-philippe.waroquiers@skynet.be> <20180826165359.1600-2-philippe.waroquiers@skynet.be> <878t3yu8vv.fsf@tromey.com> <1537733790.3924.13.camel@skynet.be> Date: Mon, 24 Sep 2018 13:07:00 -0000 In-Reply-To: <1537733790.3924.13.camel@skynet.be> (Philippe Waroquiers's message of "Sun, 23 Sep 2018 22:16:30 +0200") Message-ID: <87tvmfniwi.fsf@tromey.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2018-09/txt/msg00804.txt.bz2 >>>>> "Philippe" == Philippe Waroquiers writes: Tom> I tend to think this should go somewhere else, since cli-utils is more Tom> like "low level" parsing helpers. But I don't really know where I Tom> guess. Philippe> Yes, I found no better (existing) place, so I kept it there. Philippe> If you prefer, I can create cli-arg_utils.h for 'higher level' Philippe> arg parsing helpers if you believe this is cleaner. I think your current approach is fine. Philippe> I looked at using gdb_argv, but concluded that using gdb_argv Philippe> would be backward incompatible for some likely use cases. [...] Philippe> So, I did not switch fully to gdb_argv, but made Philippe> extract_arg_maybe_quoted quoting and escaping compatible Philippe> with gdb_argv. Thank you for looking into this. Tom> One question I have is whether we could just change extract_arg to do Tom> the dequoting. Auditing the existing calls to see if this change would Tom> negatively impact them might not be too hard. And, it would be nice to Tom> make gdb's CLI a bit more regular. Philippe> I examined the calls to extract_arg : I found one possible unlikely Philippe> backward incompatibility related to single quote handling : Philippe> the mem command accepts expressions for addresses, and expressions Philippe> in Ada can contain single quotes. C-ish languages use single quotes for char constants, so this would be pretty bad there too. The "mem" command got the parsing wrong. The incorrectness dates back to when it was introduced in 2001. For example (today's code but it hasn't substantially changed): std::string tok = extract_arg (&args); if (tok == "") error (_("no lo address")); lo = parse_and_eval_address (tok.c_str ()); This is user-hostile for non-trivial expressions, because it forces you to write them without spaces. Instead code like this should use parse_to_comma_and_eval. Maybe it is too late to fix the "mem" command. I am not sure. I do know that back when I approved a similar change to "disasssemble" (I thought I'd written that! But the history shows not), there were complaints -- we broke people's workarounds for the bad parsing behavior. On the other hand, "disasssemble" is probably used a lot more than "mem". Philippe> So, it looks possible to have extract_arg behaviour replaced by Philippe> extract_arg_maybe_quoted behaviour. Philippe> If you agree with the above analysis, I will work on that in a separate Philippe> patch series. One idea might be to upgrade the calls where it seems reasonable and then leave the legacy behavior for the ones where it is not... perhaps at the end, renaming extract_arg so that the name makes it clear that it shouldn't be used in new code. What do you think of that? It's not necessary for you to do all the work involved. Tom