From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8371 invoked by alias); 16 Jun 2010 18:18:31 -0000 Received: (qmail 8355 invoked by uid 22791); 16 Jun 2010 18:18:29 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 16 Jun 2010 18:18:04 +0000 Received: (qmail 11954 invoked from network); 16 Jun 2010 18:18:03 -0000 Received: from unknown (HELO macbook-2.local) (stan@127.0.0.2) by mail.codesourcery.com with ESMTPA; 16 Jun 2010 18:18:03 -0000 Message-ID: <4C191555.5060404@codesourcery.com> Date: Wed, 16 Jun 2010 18:18:00 -0000 From: Stan Shebs User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Doug Evans CC: Stan Shebs , "gdb@sourceware.org" Subject: Re: [RFC] Collecting strings at tracepoints References: <4C0983C3.6000604@codesourcery.com> <4C18163D.5090802@codesourcery.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2010-06/txt/msg00062.txt.bz2 Doug Evans wrote: > On Tue, Jun 15, 2010 at 5:09 PM, Stan Shebs wrote: > >> I just threw "@/" out there as something that was parseable. @ is a totally >> general binary operator, the second argument doesn't have to be a constant >> (not even for tracing). So any extensions to it need to be something that >> is not ambiguous with anything else. "@@" for the common case seemed >> logical. Allowing both "@@" and "@@" could get us into dangling-else >> style ambiguity; given that this is our arbitrary extension, why create >> parsing ambiguity if there is no language syntax forcing us to? >> > > I don't quite follow. > You're going from @ being a binary operator and extending it, to > concerns of @@ vs @@. > Guessing, you're not really extending @ except visually. > > That's right. Partly because the expedient for string collection right now is "*str@40", so it extends a known behavior, and partly because '@' is about the only character that isn't already claimed by language and/or GDB command syntax. As far as parsing goes, it wasn't obvious to me whether it make more sense to add new tokens like "@@" etc, or to add syntax rules using single-char tokens. I haven't actually tried implementing anything yet, although looking at the calendar, I think I'd better get busy. :-) It occurs to me that /s and @@ are not mutually exclusive, and it wouldn't be bad if both forms were available. Users like it when they can guess at the syntax and everything works as expected. :-) Stan