Undefined behaviours in D and C

[Michel Fortin]

On 2010-04-17 13:35:16 -0400, Walter Bright <newshound1 at digitalmars.com> 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
michel.fortin at michelf.com
http://michelf.com/