breakpoint for accessing memory location

[Rodney M. Bates]

Eli Zaretskii wrote:
>> 
> Are there any more examples beyond p->f?  That is, what other
> situations are there where the context can matter?  Are we talking
> only about portions of expression going out of context (and thus
> becoming invalid), or are there other problems?
> 
> (You see, I don't think I understand what you mean by ``the semantics
> of evaluating a watchpoint expression'', and a single example you gave
> is not enough for me to figure that out.)
> 

Well, an expression in a program is always interpreted by looking up
any unqualified identifiers according to the scope rules, at the place in the
code where the expression appears.  But with a watchpoint, that place keeps
changing.  p can go out of scope, come back in, or a different p could become
visible.  So more example questions (same expression, different contexts):

If execution gets to where there is no p visible, does the watch get
permanently disabled?  Does execution stop?  Does the watch just get ignored
for now.  If execution comes back into the original scope, does the
expression start getting watched again?

If execution goes somewhere where a different p is visible, does the
watch get disabled?  temporarily ignored?  Is the expression reevaluated
using the new p?  What if this is type-incorrect (e.g. p is not a pointer, or
points to something that doesn't have an f)?  What if a different p points
to the same struct type or a different struct type that also has an f,
and the second f is the same type as the first, or a different type?

What if p is a variable in the original context but a type name in a later
context?  (Maybe there are no expressions that would be legal both ways?)

If the expression is illegal at the place where the program is stopped
when the watch is typed, is it rejected then and there, or kept around
in case, e.g., a p comes into scope.

I realize that the answer to one of my first questions could make the rest
of them irrelevant.  And I presume that just a change in the value of the
same p, while it remains in scope, means the watch now looks for changes to
the f of the new struct p points to, but even this might be worth explaining
explicitly.

As for different expressions, the only thing I think of that could matter
is each occurrence of an unqualified identifier, and these would all presumably
be independent.

-- 
-------------------------------------------------------------
Rodney M. Bates, retired assistant professor
Dept. of Computer Science, Wichita State University
Wichita, KS 67260-0083
316-978-3922
rodney.bates@wichita.edu