From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-patches-return-134695-listarch-gdb-patches=sources.redhat.com@sourceware.org>
Received: (qmail 57117 invoked by alias); 9 Nov 2016 18:51:32 -0000
Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <gdb-patches.sourceware.org>
List-Subscribe: <mailto:gdb-patches-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb-patches/>
List-Post: <mailto:gdb-patches@sourceware.org>
List-Help: <mailto:gdb-patches-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: gdb-patches-owner@sourceware.org
Received: (qmail 57100 invoked by uid 89); 9 Nov 2016 18:51:31 -0000
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-4.8 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=bouncing, Heres, Here's
X-HELO: mx1.redhat.com
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 09 Nov 2016 18:51:30 +0000
Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23])	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))	(No client certificate requested)	by mx1.redhat.com (Postfix) with ESMTPS id 4AEC08F283;	Wed,  9 Nov 2016 18:51:29 +0000 (UTC)
Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11])	by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id uA9IpSSc011662;	Wed, 9 Nov 2016 13:51:28 -0500
Subject: Re: [PATCH v2 2/5] Further cleanup/modernization of gdb.base/commands.exp
To: Simon Marchi <simon.marchi@polymtl.ca>
References: <1478650771-24430-1-git-send-email-palves@redhat.com> <1478650771-24430-3-git-send-email-palves@redhat.com> <994221f0964b21175ece863b9e4eed59@polymtl.ca> <1e856161-24c0-5f93-7847-a2bf9af57e8c@redhat.com> <c018dbb5-5aeb-8e90-38a9-f4c7aa29d39f@redhat.com> <937642fa3965d4029b5c98cb84a26954@polymtl.ca> <835da2d0-1d1a-907d-420e-5332f3336a9b@redhat.com> <9d7681f17b6ab79976fdc9e3ae18632c@polymtl.ca>
Cc: gdb-patches@sourceware.org
From: Pedro Alves <palves@redhat.com>
Message-ID: <7e65500d-ba4a-6ccd-a75c-14d8d2c27f1e@redhat.com>
Date: Wed, 09 Nov 2016 18:51:00 -0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <9d7681f17b6ab79976fdc9e3ae18632c@polymtl.ca>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
X-SW-Source: 2016-11/txt/msg00235.txt.bz2

On 11/09/2016 04:24 PM, Simon Marchi wrote:
> On 2016-11-09 11:16, Pedro Alves wrote:
>> On 11/09/2016 04:09 PM, Simon Marchi wrote:
>>> On 2016-11-09 10:59, Pedro Alves wrote:
>>>> And I'm wondering whether this below as well would be a good idea,
>>>> or whether it'd obfuscate?  If a good idea, maybe we'd put the new
>>>> variable in gdb.exp.
>>>
>>> ...
>>>
>>>> @@ -45,7 +50,7 @@ proc_with_prefix gdbvar_simple_if_test {} {
>>>>           "else" \
>>>>           "  p/x 0xdeadbeef" \
>>>>           "end"] \
>>>> -    "\\\$\[0-9\]* = 0xdeadbeef" \
>>>> +    "$valnum_re = 0xdeadbeef" \
>>>>      "#1"
>>>
>>>
>>> That's not bad.  I was going to suggest using {} instead of "" to get
>>> rid of most backslashes (untested):
>>>
>>> -"\\\$\[0-9\]* = 0xdeadbeef"
>>> +{\$[0-9]* = 0xdeadbeef}
>>>
>>> but with the variable it looks good as well.
>>>
>>
>> Here's the resulting squashed patch then.  WDYT?
> 
> LGTM.
> 

Thanks for all the review and bouncing off ideas.  I've pushed in
the version using {} throughout.