On 2010-04-17 13:35:16 -0400, Walter Bright <[email protected]> said:
BCS wrote:
Currently the described code is legal, unsafe (it can result in invalid
pointers) and has undefined semantics (it can result in unpredictable,
implementation defined results). What I think bearophile wants is for
only the last to be changed, that is; you can still do things that
result in invalid pointers, but it does so in a well defined way (at
least with regards to the bit pattern the pointer ends up as)
I don't think that's a useful thing to specify - where's the advantage,
and if D is on a machine that does pointers differently, why make it
impossible to port standard D to it?
Me thinks this is not a very good argument. Supporting obscure
platforms isn't very useful, that's why D only supports complement-2
arithmetics (you said it yourself).
There is a very good reason to disallow manipulating the bit pattern in
safe D however: memory safety. If you can dereference a pointer made
from an arbitrary bit pattern, you may have an exploitable flaw similar
to a buffer overrun. Dereferencing an arbitrary value is definitely
*not* memory-safe and should *not* be allowed in safe D.
So you shouldn't be able to cast a value to a pointer. The reverse,
casting a pointer to a value, makes sense in my opinion: you may want
to print the pointer value in a debug output of some sort. There's
nothing unsafe with that so it should be allowed.
--
Michel Fortin
[email protected]
http://michelf.com/
