Thu Apr 10 09:43:00 GMT 2003
-----BEGIN PGP SIGNED MESSAGE-----
Am Dienstag, 8. April 2003 21:08 schrieb Andrew Haley:
> Tom Tromey writes:
> > >>>>> "Michael" == Michael Koch <email@example.com> writes:
> > Michael> Execept the copyright statement and package name both
> > java Michael> files are identical. Thats why I thought they
> > could be Michael> merged.
> > I've been wondering, but haven't yet brought up, whether this is
> > something Classpath really wants to do. It imposes a cost on
> > all implementing VMs, and compilers.
> > Note that we don't even handle RawData properly -- for instance
> > I think `Object foo = <Rawdata>' should be invalid. Any cast to
> > RawData should also be rejected by the compiler.
> Yes. Some code assumes that everything is a subclass of Object and
> so we don't need to check the cast. This is a good optimization.
> RawData breaks the type system in this regard.
> > Likewise the interpreter and verifier probably need special
> > cases here. There may be other problems, in reflection or JNI.
> > I'm not sure.
> > Hmm, maybe we should get rid of it and use long :-)
> I'm wondering if it might be a good idea to have a type which is
> the equivalent of "integer attribute ((mode(pointer)))" or
> somesuch. However, it wouldn't need to be an arithmetic type.
> We could then replace all instances of RawData with that. We
> wouldn't be able to use it for an IdentityHashmap key, which would
> be a shame.
> > If Classpath does continue with this, we could consider
> > changing. A patch to do this would also have to change the
> > compiler (that's easy in this case though).
> Seems reasonable.
It is possible to use long instead of RawData. But then we need
conversion methods I think (void* -> jlong, jlong -> void*). With
RawData we can just use a <reinterpret_cast> which has more ore less
no cost at runtime.
As I understand it using long is in general more safe in regard to
security holes, right ? We will have to do a lot of work to make sure
we are on the safe side when we use RawData overall.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
-----END PGP SIGNATURE-----
More information about the Java