Messages in this thread |  | | From | Keith Rohrer <> | Subject | Re: Linux for JavaVM | Date | Fri, 17 Jan 1997 14:53:26 -0600 (CST) |
| |
> > Yes: you are wrong. The bytecode does NOT support such C features as > > "dereference an arbitrary pointer". I don't know about the bytecode, but I do know that Java is paranoid about pointers to the extent that, short of a few classes in java.lang.io (or somewhere like that) grab a contiguous block of memory; afaik, the code "byte foo[50];" declares foo to be 50 _references_ to ints... Plus, absolutely everything is signed.
> > The Java VM is supposed to afford a > > safe, "boxed", environment for arbitrary Java code snippets. You can't do > > that if you would ever allow the bytecode equivalent of perfectly-legal C > > code such as "*(char *)0x123456 = 0x78" to run. > Sure you can. You just have to either make sure 0x123456 is a memory > location the applet is allowed to access, or fault. This is a > function of the byte code interpreter. And the last thing I expect to see in Java is an option for "inline bytecode"...
> The Linux kernel allows C > programs to do *(char *)0x123456 = 0x78; for example, but that doesn't > give them access to arbitrary memory locations. This is a feature of > the CPUs used. When you write a byte code interpreter (or compiler) > you are doing a "virtual CPU", in effect, so you can define it to have > whatever security features you choose. However, needing a special java vm which is lax enough to run linuj is likely to defeat whatever point there was to using java in the first place.
> Note that that doesn't mean the Java spec supports this kinds of > operations (AFAIK it doesn't) but it doesn't mean it isn't possible. Sorry I didn't get in on this thread early enough to know just what reason someone had for suggesting "linuj", but I can't think of any of the usual reasons besides "portability"...
Keith
|  |