Safe mode in D?

Maxim Fomin maxim at maxim-fomin.ru
Thu Oct 17 23:53:44 PDT 2013


On Thursday, 17 October 2013 at 22:56:04 UTC, DDD wrote:
> Hi I heard that you can pass a command line argument to make D 
> safe. Like 0 chance of memory corruption and such. I tried 
> looking here http://dlang.org/dmd-linux.html but I couldn't 
> figure it out. If it matters I'm on windows using the latest 
> until a new version came out ~3weeks ago

Safe code in D is defective feature and claims that D's code can 
be memory safe is the biggest misconception!

First of all, @safe is broken, which means there are many cases 
when code should be rejected, but actually isn't, secondly it is 
misdesigned. Root of the issue is that in D static type system 
and memory safity are separated from each other. Key idea is that 
having information about static type of object is not sufficient 
to know whether using it is memory safe or not.

@safe foo(int[] arr) {}

void main @safe()
{
    int [3] x;
    // auto dg = { return x; } ;
    foo(x[]);
}

This a nice case to show @safe problems. First of all, passing 
static array to dynamic is of relative safety: if slice doesn't 
escape, this is fine, if is does, this can be still fine if it 
later for example is appended (or any operation is performed 
which does not access any elements). Otherwise it is a memory 
bug. In a presence of separate compilation this is impossible to 
know. In such cases memory safety is at best undefined. Other 
issue here is that if delegate declaration is uncommented, then 
code is always memory safe because array will be allocated on 
heap. However, by @safe definition code will be still rejected, 
because @safe is defined in notion of static type rather than 
memory type. Last issue here is that implementation is buggy and 
does not reject the code in accordance with its buggy spec.

And at last, there are cases in the language which are not 
covered by @safe spec, but which still produce memory errors.

So, what actually D has, is a feature, which does not really 
prevents memory errors, but bans some language features and 
criteria for banning features is wrong: some legal cases are 
banned, some cases which should be blocked, are not. If you are 
really interested in safety you can put our attention to 
languages like C#. D doesn't provide such facilities.


More information about the Digitalmars-d mailing list