safeD

jerro a at a.com
Sat Mar 9 12:47:03 PST 2013


On Saturday, 9 March 2013 at 19:47:12 UTC, Mark T wrote:
> On Saturday, 9 March 2013 at 19:07:31 UTC, jerro wrote:
>>> Is this suitable for embedded targets such as ARM Cortex 32 
>>> bit?
>>
>> For ARM, your best bet is to follow this guide to build a GDC 
>> cross-compiler (probably easiest to build on a Linux host):
>>
>> http://gdcproject.org/wiki/Cross%20Compiler/crosstool-NG
>>
>> I don't know what kind of ARM Cortex you have in mind and what 
>> OS do you need to use. If you mean Cortex A8, A9 or A15 and if 
>> your target OS is GNU/Linux, then you can use Druntime and 
>> Phobos. I haven't used GDC on ARM enough to know if everything 
>> in Druntime and Phobos works, but the parts that I have used 
>> did work. In this case you should be able to SafeD too, as 
>> it's just a subset of D.
>
>    Thanks for the input - but where is SafeD defined?

It is described in "The D programming language book". There's 
also something about it in "Programming in D" book, but that part 
hasn't been translated to English yet. People have written about 
SafeD in other places too, but I can't remember any.

> Is there a compiler switch?

There are attributes @safe, @trusted and @system, that are used 
like this:

void foo() @safe
{
     //some code
}

or

@safe
{
     void foo() @safe{}
     void bar() @safe{}
}

or (this will affect all the functions from @safe: to the end of 
the scope):

@safe:

void foo(){}
void bar(){}

The code that is marked as safe can't use certain language 
features (For example
pointer arithmetic and casting pointers - I haven't used @safe 
enough to know all the restrictions) or call functions that are 
marked @system. Also, some new restrictions (related to returning 
by reference) will need to be added to @safe, because it was 
recently discovered that it is currently possible to write @safe 
code that is not actually memory safe.

@system and @trusted code can use all D features and call all 
functions. The difference between them is that @trusted functions 
can be called by @safe code and @system functions can not.

For templates, safety is inferred from implementation if there 
are no attributes, and ordinary functions are considered @system 
by default.

> I haven't looked at D in a while, it was just too big for ARM 
> Cortex M, smaller PowerPC and similar targets - a google search 
> got me to the SafeD topic.

If D needs to much memory or if the executables are too large for 
your use case,
SafeD will not make it any better. It will actually make it 
worse, because it makes manual memory management impossible (it 
prohibits calling malloc or casting between pointer types), if 
used consistently.


More information about the Digitalmars-d mailing list