safety model in D

[Andrei Alexandrescu]

Don wrote:
> Andrei Alexandrescu wrote:
>> SafeD is, unfortunately, not finished at the moment. I want to leave 
>> in place a stub that won't lock our options. Here's what we currently 
>> have:
>>
>> module(system) calvin;
>>
>> This means calvin can do unsafe things.
>>
>> module(safe) susie;
>>
>> This means susie commits to extra checks and therefore only a subset 
>> of D.
>  >
>  > module hobbes;
>  >
>  > This means hobbes abides to whatever the default safety setting is.
> 
> Where did susie come from?  Only module(system) has been discussed
> before.

Well actually it's always been at least in the early discussions, I was 
actually surprised that dmd doesn't yet accept it lexically.

> Why the need for THREE types of modules? Distinguishing hobbes 
> and susie seems pointless -- either hobbes is safe, or else it will not 
> compile with the -safe switch (and it won't compile at all, on a 
> compiler which makes safe the default!!). It seems that module(safe) is 
> simply a comment, "yes, I've tested it with the -safe switch, and it 
> does compile". Doesn't add any value that I can see.

Agreed, module(safe) would be unnecessary if everything was safe unless 
overrode with "system". This would be a hard sell to Walter, however. It 
would be a hard sell to you, too - don't forget that safe + no bounds 
checking = having the cake and eating it.

module(safe) is not a comment. We need three types of modules because of 
the interaction between what the module declares and what the command 
line wants.

Let's assume the default, no-flag build allows unsafe code, like right 
now. Then, module(safe) means that the module volunteers itself for 
tighter checking, and module(system) is same as module unadorned.

But then if the user compiles with -safe, module(safe) is the same as 
module unadorned, and module(system) allows for unchecked operations in 
that particular module. I was uncomfortable with this, but Walter 
convinced me that D's charter is not to allow sandbox compilation and 
execution of malicious code. If you have the sources, you may as well 
take a look at their module declarations if you have some worry.

Regardless on the result of the debate regarding the default compilation 
mode, if the change of that default mode is allowed in the command line, 
then we need both module(safe) and module(system).

On a loosely-related vein, I am starting to think it would be a good 
idea to refine the module declaration some more. It's a great way to 
have fine-grained compilation options without heavy command-line options.

module(safe, contracts, debug) mymodule;

This means the module forces safety, contract checks, and debug mode 
within itself, regardless on the command line.

> As I understood it, the primary purpose of 'SafeD' was to confine the 
> usage of dangerous constructs to a small number of modules. IMHO, the 
> overwhelming majority of modules should not require any marking.

Indeed. I hope so :o).

>> \item Cross-module function calls must only go to other @safe@ modules
> 
>> 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.
> 
> This actually seems pretty similar to public/private.
> I see three types of modules:
> 
> module  : the default, should compile in -safe mode.
> module(system) : Modules which need to do nasty stuff inside, but for 
> which all the public functions are safe.
> module(sysinternal/restricted/...): Modules which exist only to support 
> system modules. This will include most APIs to C libraries.
> 
> Modules in the outer ring need to be prevented from calling ones in the 
> inner ring.

Well I wouldn't want to go any dirtier than "system", so my "system" 
would be your "sysinternal". I'd like to milden "system" a bit like in 
e.g. "trusted", which would be your "system".


Andrei