Re: Patch: FYI: remove redundant test

[Tom Tromey <tromey at redhat dot com>]

>>>>> "Andrew" == Andrew Haley <aph@redhat.com> writes:

Andrew> I'd like to suggest this alternative patch.  It removes the
Andrew> arbitrary upper limit on scanning the stack and catches the
Andrew> ArrayIndexOutOfBoundsException.  On the other hand, perhaps
Andrew> the upper limit of 6 is so that we can handle interpreter and
Andrew> native methods.  Is it okay for the invocation API when
Andrew> interpreted?

I forgot about reflection :-(.  You're right, we must handle that
correctly.

Andrew> Maybe we ought to define getCallingClass() as a macro or an inline
Andrew> method in a header file to avoid this repetition.

Sounds good.  Want to write it?

Andrew> I'm beginning to wonder if we ought to throw a security
Andrew> exception if we don't find the class.  This is for targets
Andrew> that support backtrace(), post 3.3 branch.

When we're looking for the class loader, I don't think so.  In fact,
even searching the way we do right now is a bit bogus.  Really we just
want to find the caller (skipping "synthetic" frames like ffi and also
reflection stuff).  If we're being called from some random bit of C++
code, I suppose we could just fall back on the system class loader.  I
don't see how ending up with the system class loader in some unusual
circumstance can violate the security model.  (But I'm not an expert
there either.)

When we're looking at the caller for SecurityManager, then if we can't
find the answer it might be correct to throw a security exception.  It
isn't clear.  I think it depends on the possible reasons that stack
tracing can fail.

Tom