This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: New scope checking patch


>>>>> "Rob" == Rob Quill <rob.quill@gmail.com> writes:

Tom> This seems like a good candidate for an internal function.  The syntax
Tom> is nearly identical.

Rob> Are you saying that there is something that I need to do before this
Rob> can be committed?

Sorry -- to be completely clear, I am not a gdb maintainer.
So, you are free to ignore what I say.

Rob> Where can I find out about internal functions?

There's been some discussion on the various lists.
Otherwise, the python-gdb git repository.

Or, I suppose one of us can send out a patch.

Tom> The only difference is that, at the GCC Summit, we agreed that
Tom> arguments to internal functions would be expressions.  So, instead of
Tom> $in_scope(x) you would have to write $in_scope("x").

Rob> If this patch it implemented as an internal function, what is to
Rob> stop someone passing an expression to $in_scope(), in which case,
Rob> does the patch need to be able to determine if a whole expression
Rob> is in scope?

In the internal-function form, in_scope would take a string-valued
argument.  So, the expression would be evaluated first -- just like
any other function argument -- and then passed to the in_scope
primitive.

I guess this would prevent easy checking of whether an entire
expression is in scope.  (BTW does that mean just checking all the
names in the expression?)

Tom


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]