Neat project: add pointer capability to std.bitmanip.bitfields

[Steven Schveighoffer via Digitalmars-d]

On 12/4/15 10:57 PM, deadalnix wrote:
> On Saturday, 5 December 2015 at 00:33:15 UTC, Vladimir Panteleev wrote:
>> On Friday, 4 December 2015 at 23:38:08 UTC, deadalnix wrote:
>>> On Friday, 4 December 2015 at 10:31:19 UTC, Vladimir Panteleev wrote:
>>>> I realized this was off after posting but I don't understand your
>>>> reasoning either. The size and alignment just put a bound on the
>>>> number of bits, but without verification in the setter you can't be
>>>> sure, right?
>>>
>>> If one of the bit within the alignment is not 0, that mean you did
>>> something unsafe previously to create that pointer.
>>
>> But this only applies to ... pointers to pointers, right? In D, only
>> pointer variables have to be aligned to maintain safety, and even then
>> that only applies to GC pointers (a C function may return an
>> "unaligned" pointer pointer). struct { align(1): ubyte a; int b; } is
>> still quite safe, and so is interpreting a pointer into an array of
>> ubytes as an uint.
>
> No a pointer has some alignment that depends on whatever data it points
> to. You cannot steal any bits for a char* (and taggedPointer will reject
> it) you can steal one bit from a short*, and so on. This is checked
> statically.

I think what Vladimir is referring to is an align(1) struct:

struct Foo
{
    align(1):
    ubyte a;
    int b;
}

Foo foo;
int *ptr = &foo.b; // not pointing at aligned integer

I think we should identify that tagged* does not support such pointers, 
and probably the ctor should assert this situation isn't occurring.

-Steve