|Language design/VM design email@example.com (Floris 'Tamama' van Gog) (2000-02-27)|
|Re: Language design/VM design firstname.lastname@example.org (Joachim Durchholz) (2000-03-06)|
|Re: Language design/VM design email@example.com (Jeremy Boden) (2000-03-06)|
|Re: Language design/VM design firstname.lastname@example.org (Floris 'Tamama' van Gog) (2000-03-11)|
|Re: Language design/VM design email@example.com (Jeremy Boden) (2000-03-23)|
|Re: Language design/VM design firstname.lastname@example.org (Alan Fargusson) (2000-03-23)|
|Re: Language design/VM design email@example.com (Joachim Durchholz) (2000-03-23)|
|[2 later articles]|
|From:||"Floris 'Tamama' van Gog" <firstname.lastname@example.org>|
|Date:||27 Feb 2000 02:37:47 -0500|
|Organization:||XS4ALL Internet BV|
I'm still working on my little C-hybrid for a little VM im making. The
language is extended in that it can use 'external' variables. These
are actually handles, but are in the language accessed through a
pointer of some sort. for example:
extern char *foo=function_that_returns_external_char_pointer();
'extern' is part of the type and specifies that no pointer arithmic or
anything is allowed on it. The way it works is that the foo pointer is
actually a VM-host REAL pointer, instead of a VM-address space pointer
kind of thing. The language does not allow type-casting at all, so you
can't change them in that way to let the VM crash.
Now, the way I pictured this still allows some unsafe constructs, as
in that one can use a local pointer (VM space) and change that to
point to the external pointer, then change it, and chrash the VM. I
could disallow pointer-changing for all pointers, but they are so
Another way would be to use a 'handle' but even then it would be able
to change the handle to a different one that points to different data,
and so this also has some probs.
Does anyone have some nice ideas on how to 'fix' this design? The
'extern' types are needed for what i want the VM to allow
(host-function / script variables interaction ).
Return to the
Search the comp.compilers archives again.