safety model in D

[Jason House]

Andrei Alexandrescu Wrote:

> 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.

These arguments are pretty reversible to show casting to XXX is as unsafe as casting away XXX. Consider code that creates thread-local mutable data, leaks it (e.g. assign to a global), and then casts it to immutable or shared and makes another call? To me, this is indistinguushable from the unsafe case.