safety model in D

[Andrei Alexandrescu]

Don wrote:
> Andrei Alexandrescu wrote:
>> Don wrote:
>>> Andrei Alexandrescu wrote:
>>>> Don wrote:
>>>>> Andrei Alexandrescu wrote:
>>>
>>>> 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).
>>>
>>> When would it be MANDATORY for a module to be compiled in safe mode?
>>
>> module(safe) entails safe mode, come hell or high water.
>>
>>> If module(safe) implies bound-checking *cannot* be turned off for 
>>> that module, would any standard library modules be module(safe)?
>>
>> I think most or all of the standard library is trusted. But don't 
>> forget that std is a bad example of a typical library or program 
>> because std interfaces programs with the OS.
> 
> I think it's not so atypical. Database, graphics, anything which calls a 
> C library will be the same.

I still think the standard library is different because it's part of the 
computing base offered by the language. A clearer example is Java, which 
has things in its standard library that cannot be done in Java. But I 
agree there will be other libraries that need to interface with C.

> For an app, I'd imagine you'd have a policy of either always compiling 
> with -safe, or ignoring it.

I'd say for an app you'd have a policy of marking most modules as safe. 
That makes it irrelevant what compiler switch is used and puts the onus 
in the right place: the module.

> If you've got a general-purpose library, you have to assume some of your 
> users will be compiling with -safe. So you have to make all your library 
> modules safe, regardless of how they are marked. (Similarly, -w is NOT 
> optional for library developers).

If you've got a general-purpose library, you try what any D codebase 
should try: make most of your modules safe and as few as possible system.

> That doesn't leave very much.
> I'm not seeing the use case for module(safe).

I think you ascribe to -safe what module(safe) should do. My point is 
that -safe is inferior, just some low-level means of choosing a default 
absent other declaration. The "good" way to go about it is to think your 
design in terms of safe vs. system modules.


Andrei