Safety, undefined behavior, @safe, @trusted

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Sat Nov 7 17:27:11 PST 2009


grauzone wrote:
> Walter Bright wrote:
>> grauzone wrote:
>>> Walter Bright wrote:
>>>> grauzone wrote:
>>>>> If you mean memory safety, then yes and will probably forever be 
>>>>> for all practical uses (unless D gets implemented on a Java or .net 
>>>>> like VM).
>>>>
>>>> A VM is neither necessary nor sufficient to make a language memory 
>>>> safe. It's all in the semantics of the language.
>>>
>>> Yes, but VM bytecode is a much smaller language than D, which makes 
>>> it far easier to verify for safety. In practice, SafeD will gradually 
>>> become actually safe as people use it, see it break, and you fix the 
>>> bugs. That's why I said for "all practical uses".
>>
>> The Java VM didn't start out as completely safe, either, as people 
>> found the holes they were fixed.
> 
> Because the bytecode language is much smaller than a high level language 
> like D, it's easier for Java. Also, Java was planned to be safe right 
> from the beginning, while SafeD is a rather unnatural feature added on 
> the top of a complex existing language. To make it safe, you need to 
> forbid a set of features, which inconveniences the programmer and will 
> possibly reduce code efficiency. I'm not even opposed to the idea of 
> SafeD, I'm just worrying that forcing all D code to adhere to SafeD by 
> default will cause more trouble than gain.

On the other hand, Java has had a much larger ambition, i.e. executing 
untrusted code in a sandbox, so that balances things a bit.

I may as well be wrong, but my intuition is that there are no 
insurmountable holes that would make D unusable for safe programs. I can 
clearly see the exact reasons why C++ cannot have a reasonably 
well-defined safe subset: you can't do anything of significance in C++ 
without using pointers and pointer arithmetic. (That could be mitigated 
by a library.) Anyhow, here are a few elements that I think contribute 
to D's ability to approach memory safety:

* garbage collection
* built-in arrays
* reference semantics for classes
* pass-by-reference (ref)
* safe approach to variadic functions

Without some or all of these, a safe subset of D would be more difficult 
to define and less expressive.


Andrei



More information about the Digitalmars-d mailing list