Question about garbage collection specification

[Steven Schveighoffer via Digitalmars-d]

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