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