Re: [RFC] Collecting strings at tracepoints

[Doug Evans <dje@google.com>]

On Tue, Jun 15, 2010 at 5:09 PM, Stan Shebs <stan@codesourcery.com> wrote:
> As Tom points out, it would actually be "*str@@" etc.

Yeah, I know.  I left that out as it wasn't germane to my msg.

>> That feels too inconsistent: "@@" triggers the special "up until the
>> first \0", *except* when its @/.
>> "up until the first \0" is one thing and specifying a limit is an
>> add-on.  Each should have their own syntax (e.g. str@@/80; it's
>> perhaps klunkier, but @@ is klunky to begin with. :-)]
>>
>
> 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.

> Second, it would apply to
> everything in the collection line, whether you realized it or not; I can see
> users getting burned because FUNKYTYPE is typedef'ed to char on some
> machines and not others, and so "collect /s str, funkytown" may fill the
> trace buffer unexpectedly quickly.

Ah.  I wasn't aware one could do "collect a,b,c,d".