On 2009-11-03 17:33:39 -0500, Andrei Alexandrescu
<[email protected]> said:
So these are my thoughts so far. There is one problem though related to
the last \item - there's no way for a module to specify "trusted",
meaning: "Yeah, I do unsafe stuff inside, but safe modules can call me
no problem". Many modules in std fit that mold.
How can we address that? Again, I'm looking for a simple, robust,
extensible design that doesn't lock our options.
What you want is to define the safety of the implementation separately
from the safety of the interface. A safe module interface means that
you can use the module in safe code, while a system interface forbid
using the module in safe code. You could do this with two values in the
parenthesis:
module (<interface-safety>, <implementation-safety>) <name>;
module (system, system) name; // interface: unsafe impl.: unsafe
module (safe, safe) name; // interface: safe impl.: safe
module (safe, system) name; // interface: safe impl.: unsafe
module (system, safe) name; // interface: unsafe impl.: safe
(The last one is silly, I know.)
Then define a shortcut so you don't have to repeat yourself when the
safety of the two is the same:
module (<interface-and-implementation-safety>) <name>;
module (system) name; // interface: unsafe impl.: unsafe
module (safe) name; // interface: safe impl.: safe
Of note, this also leaves the door open to a more fine-grained security
policy in the future. We could add an 'extra-safe' or 'half-safe' mode
if we wanted.
--
Michel Fortin
[email protected]
http://michelf.com/
