From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17841 invoked by alias); 9 Apr 2008 20:37:54 -0000 Received: (qmail 17829 invoked by uid 22791); 9 Apr 2008 20:37:53 -0000 X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.33.17) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 09 Apr 2008 20:37:36 +0000 Received: from zps37.corp.google.com (zps37.corp.google.com [172.25.146.37]) by smtp-out.google.com with ESMTP id m39KbR0P021933 for ; Wed, 9 Apr 2008 21:37:27 +0100 Received: from wa-out-1112.google.com (wafl24.prod.google.com [10.114.188.24]) by zps37.corp.google.com with ESMTP id m39KbFPG023670 for ; Wed, 9 Apr 2008 13:37:26 -0700 Received: by wa-out-1112.google.com with SMTP id l24so2602581waf.22 for ; Wed, 09 Apr 2008 13:37:26 -0700 (PDT) Received: by 10.115.107.5 with SMTP id j5mr577185wam.181.1207773446185; Wed, 09 Apr 2008 13:37:26 -0700 (PDT) Received: by 10.115.107.18 with HTTP; Wed, 9 Apr 2008 13:37:26 -0700 (PDT) Message-ID: Date: Wed, 09 Apr 2008 21:06:00 -0000 From: "Doug Evans" To: gdb-patches@sourceware.org Subject: Re: [RFA] new command to search memory In-Reply-To: <20080226022335.GB4456@caradoc.them.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20080214021915.F3FE51C72F0@localhost> <20080226022335.GB4456@caradoc.them.org> X-IsSubscribed: yes 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 X-SW-Source: 2008-04/txt/msg00175.txt.bz2 On Mon, Feb 25, 2008 at 7:23 PM, Daniel Jacobowitz wrote: > And for the search string, I guess the main reason that you didn't > use the normal language parsers was to avoid the malloc call: > > > > + /* If we see a string, parse it ourselves rather than the normal > > + handling of downloading it to target memory. */ > > Can we use the language parsers, for consistency with other GDB > commands, if we fix this? Which I happen to have a patch for. I'll > dust it off and post it. Then, someday, we can get wchar_t strings > here for free (I hope). > > After that, we can (and should IMO) document in the manual that all > of the arguments to find are source language expressions. If I want to search for 'h', 'e', 'l', 'l', 'o' I won't be able to use "hello" because that will now include the trailing nul. Often one will want the trailing nul, but it does make searching for substrings kinda hard. [For completeness' sake, one could change the definition of what "hello" means in this context, and if one wants the trailing nul, one has to explicitly specify it, e.g. "hello\0". It's C-specific though, and the find command is presumably not supposed to know the user is thinking in C - that's the whole point. I don't have an opinion either way.] Any suggestions or preferences for whether and how to make searching for substrings not excessively clumsy?