Re: Java virtual machine as target language for C/C++

Note: I'm reading this in comp.compilers, and I'm not a C++ or
Java programmer. My machine was named java.agames.com before Sun
published the name, and refers to my own addiction :-) My comments are
more general...


Rinie Kervel (Drinie@xs4all.nl) wrote:
: Is it possible (and will Sun allow it) to extend the JVM to support
: pointer arithmetic.


There is more nasty stuff that gets dragged in with "pointers" as the
average C programmer mis-understands them than just "pointer
arithmetic" The next thing they "need" is a "cast", or even the
loathsome PCC "pretend this is..." rather than "convert this to..."
that has been enshrined in DOS compilers and GCC.


: Some notes:
: - Not every application is required to be secure
: (You could trust your own programs, just as you have to
: trust your web browser :)


My own programs bite me almost as often as shrink-wrap stuff, during
development. Unfortunately, my own programs are almost perpetually in
development. Comes from being a "toolsmith" to a bunch of high-strung
prima-donnas :-) And I don't really trust my browser. I have an uneasy
truce with it which would be even more uneasy if I were running a
Java-enabled browser on a mainstream machine.


: - Most pointer arithmetic can just as well be bounds checked:
: just as you can say that
: for an array a[100] a[i] is only valid if 0 <= i && i < 100


: For a pointer you can define a low address and a high addres
: and test after each operation on the pointer if it still lies
: between these bounds or is NULL (and may not be dereferenced)


This is a prime example of over-simplification. If you only need
homogeneous arrays, use homogeneous arrays. Then bounds-checking is
indeed simple and can often even be optimized away at compile time.
But a cautionary tale from my early/middle days: I'll state this in
Unix/C terms for the sake of most of the audience, but it actually
referes to a well-known high-end mainframe and its OS, circa 1970:


The OS kept the file control structures for all open files in kernel
memory, neither readable nor writeable by the user's code. The
"handle" by which a user program refered to a file was simply the
address in kernel memory of the "struct" controlling that file. The
OS "verified" the pointer by checking it against the bounds of that
program's array of such structures. But it did not verify that the
pointer actually lay on a structure boundary. A clever hacker could
(and did, at least once :-) "fopen()" a pair for files with
sufficiently odd names, attributes, etc, that a pointer somewhere
_between_ the two (and definitely passing the bounds check) would
"smell enough like" a valid pointer to be accepted by the system for
write access to a file that should have been un-available to said
hacker.


Consider the difficulty of gaining many of the advantages of
pointers, yet being safe against such attacks. By the time you are
done I would be very suprised if you have not just re-invented arrays,
with the attendant restrictions which apparently now chafe at you.


Mike


| Mike Albaugh (albaugh@agames.com) Atari Games (now owned by Williams)
| (No connection to any company owned by the Tramiel family)
| 675 Sycamore Dr. Milpitas, CA 95035 voice: (408)434-1709
--

Return to the comp.compilers page.
Search the comp.compilers archives again.