Re: how should Chain.iterator(n,n-1) work?

[John Jorgensen <jorgnsn@lcd.uregina.ca>]

>>>>> "navindra" == Navindra Umanee <navindra@cs.mcgill.ca> writes:

    navindra> Just to nitpick.  You wrote in your last commit:

    navindra> Looking at the actual updated documentation in
    navindra> Trap.java, I conclude that Trap.getBeginUnit() is a
    navindra> trapped Unit and that Trap.getEndUnit() is an
    navindra> untrapped Unit.

    navindra> So how can getBeginUnit() == getEndUnit()?

Good point. As you go on to say in a subsequent message,
getBeginUnit() == getEndUnit() when there are no longer any
trapped units at all.

I have re-revised the documentation to make that explicit, though
in the process I have boldly specified as a fact something that
perhaps "ain't necessarily so". That is, I say that when a Trap
no longer traps any units, it will be the case that

  getBeginUnit() == getEndUnit() == some_untrapped_unit

Actually, that belief is only the result of my observing that I
have encountered Traps where getBeginUnit() == getEndUnit(), and
that those cases have corresponded to Traps whose protected area
was optimized away.  I have not analyzed Soot's transformations
to verify either

 a) that when trapped units are optimized away, the labels will
    necessarily be redirected so that getBeginUnit() ==
    getEndUnit().  

or

 b) that when getBeginUnit() == getEndUnit(), it is necessarily
    the result of all the trapped units being optimized away.

Nor am I going to do so; more dutiful souls are welcome to make
the effort.

Thinking about this, incidentally, made me realize that it was
probably not an arbitrary decision to have getEndUnit() return
the first untrapped unit, rather than the last trapped
unit. Doing so allows Soot to mark the end of an exception region
with the same mechanism as it uses for non-exceptional branches:
when generating the jasmin code for the unit returned by
getEndUnit(), you precede it with a label just as you would
precede a branch target with a label, and that label marks the
end of the exception region. If getEndUnit() were the last
trapped unit, then the exception-ending label would have to
follow the generated code, rather than precede it, possibly
complicating the label-generating mechanism (though given the
difficulty I had writing a clear, concise description of what
getEndUnit() means, I wonder if special-casing the label might
not have been worth the trouble: when you have a hard time
describing what code does, maybe it's doing the wrong thing).