views:

203

answers:

2

I'm working with an unmanaged library through P/Invoke and it uses three structs (although they all have the same basic layout, so I'll only post one):

struct Agraph_t {
    int tag:4;
    int kind:4;
    int handle:24;
    char **attr;
    char *didset;
    char *name;
    Agdata_t *univ;
    Dict_t *nodes, *inedges, *outedges;
    Agraph_t *root;
    Agnode_t *meta_node;
    Agproto_t *proto;
    Agraphinfo_t u;
};

Because of the way my wrapper uses these objects, I have to refer to structs inside Agraph_t as IntPtrs. I added properties that make accessing the values of the bit fields easier.

public struct Agraph_t {
    public uint tag_kind_handle;
    public IntPtr attr;
    public string didset;
    public string name;
    public IntPtr univ;
    public IntPtr nodes, inedges, outedges;
    public IntPtr root;
    public IntPtr meta_node;
    public IntPtr proto;
    public IntPtr u;

    public uint Tag {
        get { return (tag_kind_handle & 15u); }
    }

    public uint Kind {
        get { return (tag_kind_handle & 240u) / 16; }
    }

    public uint Handle {
        get { return (tag_kind_handle & 4294967040u) / 256; }
    }
}

Before doing anything, I have to initialize the unmanaged library by giving it the size of each of the three structs.

aginitlib(Marshal.SizeOf(typeof(Agraph_t)), ..., ...);

I don't get an error when doing that and I can use the library just fine. However, part of the library makes its own call to aginitlib (I have no control over this) using the size of the unmanaged structs. At that point, the library warns me that it has been initialized with two different sizes, which is making it unstable (throwing AccessViolationExceptions after certain operations).

Are the added properties being factored into the size of the struct and making it larger than the unmanaged version? I would remove them and see what happens, but my code depends heavily on them, which makes that difficult.

Do I need to use StructLayoutAttribute with the Size property? The only thing that confuses me about that is the IntPtrs. The library is strictly 32-bit, so can I go ahead and safely assume that those fields will be 32 bits all the time?

+1  A: 

IntPtr is 4-bytes wide in 32bit code and will be 8-bytes long in 64bit mode.

You can determine the size by using the IntPtr.Size property, which reports the size of the value for the current runtime.

As for your other question, you should really use StructLayoutAttribute to ensure that the managed and unmanaged structures are laid out in memory in the same way,with the same padding and field sizes.

You will also need to remove the properties from the struct, since they will affect the size of the structure in memory.

LBushkin
"You will also need to remove the properties from the struct, since they will affect the size of the structure in memory." This is not correct. Properties are metadata and occupy space *per type*, not per instance. (Your comment would be true if the properties had their own backing fields, but they don't: they're just getter methods over the tag_kind_handle field.)
itowlson
+1  A: 

The difference is because of the declaration for u. The unmanaged declaration has this:

Agraphinfo_t u;

This means that an Agraphinfo_t is allocated inline in the Agraph_t struct. If Agraphinfo_t is, say, 16 bytes in size, then it contributes 16 bytes to sizeof(Agraph_t).

However, in your managed declaration, you declare u like this:

public IntPtr u;

This means that a pointer is allocated in the Agraph_t struct. On a 32-bit system, this will contribute 4 bytes to sizeof(Agraph_t). Hence the two sizes computed for Agraph_t are out of sync.

To fix the problem, declare a managed equivalent to Agraphinfo_t and create an instance of that in Agraph_t:

public struct Agraphinfo_t
{
  // fields go here as per unmanaged definition
}

public struct Agraph_t
{
  // ....
  public Agraphinfo_t u;
}
itowlson
Oh, I see. I didn't notice the missing `*`. The problem with this solution is that the `Agraphinfo_t` struct is MASSIVE (in terms of number of fields) and uses different fields depending on how the library was compiled. I have no idea what compiler flags were used, so I'm not sure which fields to include. Any tips?
David Brown
Unfortunately not. To get the sizes to match, you're going to need to provide *something* in that slot that occupies the same amount of size (in the struct) as the unmanaged `Agraphinfo_t` structure. You might be able to use a byte array (with suitable marshalling flags to ensure it's treated as inline space rather than a reference), but that will still require you to calculate the size... though I guess you could do this by writing a little C program to printf the `sizeof(Agraphinfo_t)`. No promises, though -- sorry!
itowlson
That sounds doable. In the meantime, I've added the requirement that the part of the library that makes its own call to `aginitlib` should be called before anything else and removed the ability to call it manually from the managed wrapper. It works, but definitely isn't a requirement I'd like to keep.
David Brown