This is the mail archive of the java@gcc.gnu.org mailing list for the Java 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: gcj is not type-safe


Tom Tromey wrote:
> >>>>> "Gary" == Gary Benson <gbenson@redhat.com> writes:
> 
> Gary> While testing on a patch for this I realised there's two ways
> Gary> to spoof a method: you can spoof the return type, like we're
> Gary> doing, or you can spoof a parameter.
> 
> Yeah, the code in link.cc ought to check both the parameter types
> and the return type.

It does, now :)

> Gary> Spoofed return types and fields are caught in Sun Java by the
> Gary> initiating loader check [1] but spoofed parameters are caught
> Gary> explicitly [2], and if you spoof _both_ a parameter and the
> Gary> return type then it's the parameter that gets caught.  So it
> Gary> looks like they don't check the return type when they check
> Gary> the signature.
> 
> I think it probably doesn't matter which check catches the problem
> in our implementation, provided we catch it and the appropriate
> exception is thrown.  (Sometimes I think there may be multiple valid
> possible exceptions; but I didn't look to see if that is the case
> here.)

Sun throws LinkageErrors in both cases.  The messages differ,
obviously, but the exceptions are the same type.

> We probably do also need an initiating loader check.  Otherwise
> maybe an instanceof check, or superclass link, or an actual cast
> could be spoofed.

I checked these: instanceof and cast both throw ClassCastExceptions,
and the verifier catches cases when you try to sneak in a different
superclass.  I presume these cases are all handled with pointers.
I'm still going to implement the initiating loader check though.

Cheers,
Gary


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