safety model in D

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Tue Nov 3 21:15:45 PST 2009


Jason House wrote:
> Walter Bright Wrote:
> 
>> Andrei Alexandrescu wrote:
>>> Sketch of the safe rules:
>>> 
>>> \begin{itemize*} \item No @cast@ from a pointer type to an
>>> integral type and vice versa
>> replace integral type with non-pointer type.
>> 
>>> \item No @cast@ between unrelated pointer types \item Bounds
>>> checks on all array accesses \item  No  unions  that  include  a
>>> reference  type  (array,  @class@, pointer, or @struct@ including
>>> such a type)
>> pointers are not a reference type. Replace "reference type" with 
>> "pointers or reference types".
>> 
>>> \item No pointer arithmetic \item No escape of a pointer  or
>>> reference to a local variable outside its scope
>> revise: cannot take the address of a local or a reference.
>> 
>>> \item Cross-module function calls must only go to other @safe@
>>> modules \end{itemize*}
>> add: . no inline assembler . no casting away of const, immutable,
>> or shared
> 
> How does casting away const, immutable, or shared cause memory
> corruption?

If you have an immutable string, the compiler may cache or enregister
the length and do anything (such as hoisting checks out of loops) in 
confidence the length will never change. If you do change it -> memory 
error.

> If I understand SafeD correctly, that's its only goal. If it does
> more, I'd also argue casting to shared or immutable is, in general,
> unsafe. I'm also unsure if safeD has really fleshed out what would
> make use of (lockfree) shared variables safe. For example, array
> concatenation in one thread while reading in another thread could
> allow reading of garbage memory (e.g. if the length was incremented
> before writing the cell contents)

Shared arrays can't be modified.


Andrei



More information about the Digitalmars-d mailing list