View mode: basic / threaded / horizontal-split · Log in · Help
March 09, 2013
safeD
Where can I find more information on SafeD?

http://dlang.org/safed.html

google didn't seem to find much

Is this suitable for embedded targets such as ARM Cortex 32 bit?

thanks

Mark
March 09, 2013
Re: safeD
> 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.

For Android there's a fork of GDC at 
https://github.com/jpf91/GDC/tree/android, but it hasn't been 
updated for some time now. There are build scripts that build NDK 
with gdc support at https://github.com/jpf91/gdc-android-scripts. 
I don't know how well that fork works. Also, GDC's Druntime does 
not support shared libraries, which is a problem if you want to 
call D functions from java apps.

If you are using some other OS or no OS at all, I don't think 
there is a working version of Druntime you can use. In that case, 
you could probably still use D, but without Druntime. You would 
need to write stubs for some Druntime functions to avoid linker 
errors, and you would need to avoid any D features that use 
Druntime. Because of that, you couldn't use any feature that use 
a GC, such as operator new, associative arrays, closures or 
appending to slices. This would also make it impossible to 
effectively use SafeD (because you wouldn't be able to allocate 
memory). You could port Druntime to your platform, but I guess 
this is a lot of work.
March 09, 2013
Re: safeD
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? Is there a 
compiler switch?
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.
March 09, 2013
Re: safeD
On Saturday, March 09, 2013 20:47:10 Mark T wrote:
>     Thanks for the input - but where is SafeD defined? Is there a
> compiler switch?

No. It's simply code that's @safe. If you mark your functions as @safe, then 
they can only can @safe and @trusted functions and can't do any operations 
that the language considers to be @system (e.g. pointer arithmetic). So, what 
it comes down to is that you have certain safety guarantees about any code 
that's marked @safe. It's not really a separate language. It's just that you 
can only use a subset of the language within @safe code, because you can only 
use stuff that's guaranteed to be safe (though when calling @trusted code, you 
_do_ still rely on the programmer who wrote it having verified that it was 
actually safe, and they could screw that up).

Certain language constructs and core library components are not yet @safe like 
they should be, and attribute inferrence for templates still needs a lot of 
work (templated functions infer whether they're @safe, nothrow, and/or pure), 
so there's a lot of templated stuff that's perfectly safe but doesn't get 
treated that way yet. So, you're probably going to have to use @trusted more 
than would be desirable (and certainly more than you'll have to in the 
future), but on the whole, @safe itself works just fine. But it's part of the 
language, not something triggered by a compiler switch.

- Jonathan M Davis
March 09, 2013
Re: safeD
On Saturday, 9 March 2013 at 19:47:12 UTC, Mark T wrote:
>    Thanks for the input - but where is SafeD defined? Is there 
> a compiler switch?
> 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.

No, you don't need to compiler switch. What you need is to mark 
functions as @safe. E.g:

@safe void safe_foo()
{
}

If you don't mark them they are considerded @system.
March 09, 2013
Re: safeD
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.
Top | Discussion index | About this forum | D home