Passing "object" to native DLL is dangerous about hdf.pinvoke HOT 4 CLOSED

Very interesting. I'm on x64 and all tests pass. Let me take a closer look.

from hdf.pinvoke.

Please pull the latest version. Everything passes for me on x86 and x64. Please confirm.

from hdf.pinvoke.

Now all tests pass for me, too.
Redeclaring the operator_t type to take an IntPtr is surely correct.
What I consider still dangerous, is that GCHandle.Alloc() without the Pinned flag allows the GC still to move the allocated object around (which could happen any time).
From my point of view, something like this would be bulletproof:

GCHandle hnd = GCHandle.Alloc(aObj, GCHandleType.Pinned);
IntPtr aAdr = hnd.AddrOfPinnedObject();
H5A.iterate(...,cb, aAdr);
hnd.Free();

The downside of this is, that you cannot "pin" interesting .NET objects (like collections). But with the current declaration of the callback-function, it's completely up to the user, what she is passing in to the callback, so it's fine...

from hdf.pinvoke.

I would like to believe that I read somewhere that when passing a PInvoke boundary, the runtime automatically pins those handles. Maybe just wishful thinking... I'll close it for now and re-open as needed. There's another batch of callback APIs coming...

from hdf.pinvoke.