Re: [RFC] Collecting strings at tracepoints

[Stan Shebs <stan@codesourcery.com>]

Doug Evans wrote:
> On Tue, Jun 15, 2010 at 5:09 PM, Stan Shebs <stan@codesourcery.com> 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 "@@<expr>" 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 @@<expr>.
> 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