On 6/15/15 11:49 AM, Alex Parrill wrote:
On Monday, 15 June 2015 at 15:33:41 UTC, rsw0x wrote:
this doesn't make any sense, it's referring to an object p (of void*),
not the location of p. It's setting the lsb of p to 1 and claiming
it's undefined behavior, when it's clearly not.
Unless I misunderstand it.
`p` is assumed to be a pointer. `cast(int) p` gets the integer
representation of the pointer (though it should be `uintptr_t` but
whatever). It then does an integer bitwise or, then converts the result
back to a pointer.
It's undefined behavior in D because the spec just said so (regardless
of its defined behavior in C).
Where? In the GC document? I don't think that document is correct in
this regard. Undefined behavior is something different than
implementation defined behavior, which is what this is. The spec says
(http://dlang.org/type.html):
"Casting pointers to non-pointers and vice versa is allowed in D,
however, do not do this for any pointers that point to data allocated by
the garbage collector."
How can the compiler POSSIBLY know whether a pointer points at GC data
in order to make it undefined behavior?
I don't see any justification for any of these restrictions. The "to
allow maximum flexibility" justification needs more explanation, what
possible feature could you implement given this restriction?
It even allows using unions to do exactly the same thing. There is just
no way this cannot be allowed.
-Steve
