From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21414 invoked by alias); 2 Oct 2019 17:30:41 -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 21270 invoked by uid 89); 2 Oct 2019 17:30:32 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-18.7 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.1 spammy=H*r:172.16.0 X-HELO: simark.ca Received: from simark.ca (HELO simark.ca) (158.69.221.121) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 02 Oct 2019 17:30:15 +0000 Received: from [172.16.0.120] (192-222-181-218.qc.cable.ebox.net [192.222.181.218]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id DCB981E08E; Wed, 2 Oct 2019 13:30:05 -0400 (EDT) Subject: Re: New ARI warning Wed Oct 2 01:56:22 UTC 2019 To: Tom Tromey Cc: GDB Administrator , gdb-patches@sourceware.org References: <20191002015622.GA57488@sourceware.org> <875zl7yvhy.fsf@tromey.com> From: Simon Marchi Message-ID: Date: Wed, 02 Oct 2019 17:30:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <875zl7yvhy.fsf@tromey.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2019-10/txt/msg00074.txt.bz2 On 2019-10-02 12:15 p.m., Tom Tromey wrote: > diff --git a/gdb/contrib/ari/gdb_ari.sh b/gdb/contrib/ari/gdb_ari.sh > index 4bd434c8fec..1556756a12c 100755 > --- a/gdb/contrib/ari/gdb_ari.sh > +++ b/gdb/contrib/ari/gdb_ari.sh > @@ -353,7 +353,7 @@ Do not use printf(\"%p\"), instead use printf(\"%s\",paddr()) to dump a \ > target address, or host_address_to_string() for a host address" > category["%p"] = ari_code > } > -/%p/ && !/%prec/ { > +/%p[^][sF]/ && !/%prec/ { > fail("%p") > } > My mind is a bit confused by that regex: aren't the [^] and [sF] considered as two successive character sets? If so, the caret character, which negates the character set, applies to nothing. Shouldn't there be some escaping involved? Or is the language smart enough to know that because the first ] wouldn't end a valid character set, it means it's not actually the end of the character set? Simon