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
