Blobs do not correctly account for alignment, corrupt data very easily

[rayegun]

I'm pretty sure this is very much unintended behavior, but if it's not it should be documented with a big warning sign next to it:

julia> struct Foo
           w::UInt64
           x::UInt64
           y::UInt32
           z::UInt64
       end

julia> b = Blobs.calloc(Foo)
Blob{Foo}(Ptr{Nothing}(0x0000000153725660), 0, 28) # NOTICE THE 28 HERE!

julia> sizeof(Foo)
32

julia> about(Foo)
Concrete (padded) DataType defined in Main, 32B
  Foo <: Any

Struct with 4 fields:
• w  UInt64
• x  UInt64
• y  UInt32
• z  UInt64

 ■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
        8B              8B             4B+4B            8B       

# NOTE THAT THE 4B + 4B ABOVE INDICATES 4B OF PADDING!!

julia> b.z[] = rand(UInt64)
0xd9c412513e6fc134

julia> b.z[]
0xd9c412513e6fc134

julia> unsafe_load(b)
Foo(0x0000000000000000, 0x0000000000000000, 0x00000000, 0xd9c412513e6fc134)

julia> unsafe_load(pointer(b))
Foo(0x0000000000000000, 0x0000000000000000, 0x00000000, 0x00000000d9c41251)

[rayegun]

It looks like this was potentially intentional, given how unsafe_load is implemented. But it is very easy to use the API as written and segfault if the type being wrapped contains pointers. And even without pointers if the backing storage is used elsewhere there will be data corruption.

[NHDaly]

I think the main bug with the code you posted above is that we should not implement pointer(b)::Ptr{Foo}, since - as you point out - there is not a valid Foo stored at that pointer!!!!

We can probably still allow pointer(b)::Ptr{CVoid}, since we are not making any claims about storing a Foo object in memory at that address.

But indeed, yes, the purpose of Blobs.jl is to provide fast, compacted, blob-backed storage for in-memory objects. We do implement our own equivalent to Base.reinterpret which removes and adds padding as needed when storing/loading padded structs.

Would changing the return type of pointer address the concern you've raised here?
And also probably improving the documentation to make this caveat more obvious?