On 1/17/12 6:59 AM, Don Clugston wrote:
On 17/01/12 10:40, Jonathan M Davis wrote:
On Tuesday, January 17, 2012 05:04:39 Timon Gehr wrote:
I don't know exactly, since @safe is neither fully specified nor
implemented. In my understanding, in @safe code, operations that may
lead to memory corruption are forbidden. Pointer - pointer cannot, other
kinds of pointer arithmetic may.
Pointer arithmetic is definitely forbidden in @safe, but I'm not sure
that that
forbids pointer - pointer, since it's not dangerous. It's changing a
pointer
via arithmetic which is dangerous.
- Jonathan M Davis
My guess is that safe D is supposed to enforce C pointer semantics.
At least, code which is both @safe and pure must do so.
The semantics are currently enforced in CTFE.
pointer - pointer is undefined behaviour in C, if the pointers come from
different arrays. It's OK if they are from the same array, which is true
in this case.
Yah, that C rule is to allow segmented memory architectures work
properly. One possibility for D is to require a flat memory model, in
which the difference between any two pointers can be taken.
Andrei
