http://dlang.org/garbage.html

Do not take advantage of alignment of pointers to store bit flags in the low order bits:
p = cast(void*)(cast(int)p | 1);  // error: undefined behavior

if this restriction is actually imposed - why does std.bitmanip.tagged{ClassRef,Pointer} even exist?

On Sat, 13 Jun 2015 11:32:18 +0000, rsw0x wrote:

> http://dlang.org/garbage.html
> 
> Do not take advantage of alignment of pointers to store bit flags in the
> low order bits:
> p = cast(void*)(cast(int)p | 1);  // error: undefined behavior
> 
> if this restriction is actually imposed - why does std.bitmanip.tagged{ClassRef,Pointer} even exist?

'cause D is not another fashionable scripting language where you have to eat what you got. one can avoid using GC in his code, or intermix GC with other allocators, or rewrite the whole GC or the whole runtime. writing stupid boilerplate code for tagged pointers and nan boxing is simply tedious, it belongs to library.

in other words: you can use `DirEntries` and `remove` to kill all files in your home directory, but it's not the only use for that functions, so they should not be removed from Phobos as "useless" or "dangerous".

On Saturday, 13 June 2015 at 12:26:49 UTC, ketmar wrote:
> On Sat, 13 Jun 2015 11:32:18 +0000, rsw0x wrote:
>
>> http://dlang.org/garbage.html
>> 
>> Do not take advantage of alignment of pointers to store bit flags in the
>> low order bits:
>> p = cast(void*)(cast(int)p | 1);  // error: undefined behavior
>> 
>> if this restriction is actually imposed - why does
>> std.bitmanip.tagged{ClassRef,Pointer} even exist?
>
> 'cause D is not another fashionable scripting language where you have to
> eat what you got. one can avoid using GC in his code, or intermix GC with
> other allocators, or rewrite the whole GC or the whole runtime. writing
> stupid boilerplate code for tagged pointers and nan boxing is simply
> tedious, it belongs to library.
>
> in other words: you can use `DirEntries` and `remove` to kill all files
> in your home directory, but it's not the only use for that functions, so
> they should not be removed from Phobos as "useless" or "dangerous".

There's not even a warning on them that they're violating the garbage collector specification, don't you think that's a little important?

On Saturday, 13 June 2015 at 12:28:15 UTC, rsw0x wrote:
> There's not even a warning on them that they're violating the garbage collector specification, don't you think that's a little important?

https://github.com/D-Programming-Language/phobos/pull/3411

On Sat, 13 Jun 2015 12:28:13 +0000, rsw0x wrote:

> There's not even a warning on them that they're violating the garbage collector specification, don't you think that's a little important?

i believe that if one needs to do such things, he is knowledgeable enough to foresee the possible consequences. this is not what casual programmer does, so one is expected to know some internals.

yet warning may be helpful too, Marc submitted a PR for that. ;-)

On Saturday, 13 June 2015 at 11:32:20 UTC, rsw0x wrote:
> http://dlang.org/garbage.html
>
> Do not take advantage of alignment of pointers to store bit flags in the low order bits:
> p = cast(void*)(cast(int)p | 1);  // error: undefined behavior
>
> if this restriction is actually imposed - why does std.bitmanip.tagged{ClassRef,Pointer} even exist?

That seems like an arbitrary limitation. This will create an interior pointer, which the GC needs to recognize anyway.

The doc need to be updated.

On Saturday, 13 June 2015 at 12:26:49 UTC, ketmar wrote:
> 'cause D is not another fashionable scripting language where you have to
> eat what you got. one can avoid using GC in his code, or intermix GC with
> other allocators, or rewrite the whole GC or the whole runtime. writing
> stupid boilerplate code for tagged pointers and nan boxing is simply
> tedious, it belongs to library.
>

I haven't read something that ridiculous in a while. Even if you'd be right, OP has a point in the fact that this should not be present in the standard lib without some big red sign.

Hopefully, This will work just fine with the GC. The GC spec is needlessly restrictive.

On 6/13/15 6:07 PM, deadalnix wrote:
> On Saturday, 13 June 2015 at 11:32:20 UTC, rsw0x wrote:
>> http://dlang.org/garbage.html
>>
>> Do not take advantage of alignment of pointers to store bit flags in
>> the low order bits:
>> p = cast(void*)(cast(int)p | 1);  // error: undefined behavior
>>
>> if this restriction is actually imposed - why does
>> std.bitmanip.tagged{ClassRef,Pointer} even exist?
>
> That seems like an arbitrary limitation. This will create an interior
> pointer, which the GC needs to recognize anyway.
>
> The doc need to be updated.

void *x = new int;
ptr += 1;

Is this illegal? If not, then why is the above illegal? If so, thousands of lines of code are in violation -- any kind of serialization library for example.

It's exactly the same thing. We can probably change taggedPointer to do this instead, if it's such a big deal. We can change it to a void pointer, and only cast it to T* when retrieving the real pointer.

But it seems kind of silly to outlaw the obvious implementation. I think we should revert the warning and fix the docs.

-Steve

On Sat, 13 Jun 2015 22:09:52 +0000, deadalnix wrote:

> I haven't read something that ridiculous in a while.
you're welcome.

On Saturday, 13 June 2015 at 22:07:26 UTC, deadalnix wrote:
> On Saturday, 13 June 2015 at 11:32:20 UTC, rsw0x wrote:
>> http://dlang.org/garbage.html
>>
>> Do not take advantage of alignment of pointers to store bit flags in the low order bits:
>> p = cast(void*)(cast(int)p | 1);  // error: undefined behavior
>>
>> if this restriction is actually imposed - why does std.bitmanip.tagged{ClassRef,Pointer} even exist?
>
> That seems like an arbitrary limitation. This will create an interior pointer, which the GC needs to recognize anyway.
>
> The doc need to be updated.

I see David Nadlinger already said so in the PR, but that's how I understand it:

AFAIU the purpose of this restriction is to allow the GC to take advantage of alignment: a pointer with the lowest bit set cannot point to a 4-byte aligned struct, for example. The GC doc [1] mentions alignment several times, among them:
"Do not misalign pointers if those pointers may point into the GC heap"

As for arbitrary pointer arithmetic being allowed, I guess that's because the language doesn't distinguish between GC and non-GC pointers. And note that it is un-@safe anyway.

[1] http://dlang.org/garbage.html