Re: [RFA] new command to search memory

["Doug Evans" <dje at google dot com>]

On Mon, Feb 25, 2008 at 7:23 PM, Daniel Jacobowitz <drow@false.org> 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?