Marshaling an array of boolean vs marshaling a single boolean (defined as int) to bool in C#

Question

In a C API I have BOOL defined as follows

#ifndef BOOL
#define BOOL int

And I have a struct which, among others, has a simple BOOL member and an array of BOOLs

struct SomeStruct
{
    BOOL    bIsSomething;
    BOOL    bHasSomething[5];
}

Now I found out that when I want to cast the whole struct I have to marshal them differently:

the single BOOL I marshal with I1 and the fixed length array I have to marshal with I4 (if I don't their struct sizes won't match and I will have problems extracting an array of these structs into C#):

    [StructLayout(LayoutKind.Sequential)]
    public struct SomenNativeStruct
    {
        [MarshalAs(UnmanagedType.I1)] 
        public bool bIsSomething;
        [MarshalAs(UnmanagedType.ByValArray, ArraySubType = UnmanagedType.I4, SizeConst = 5)]
        public bool[] bHasSomething;
    }

I suspect I do something wrong because I'm not sure why I should need to marshal the same type differently depending on whether I get it as a fixed size array or as a single member. If I'm marshalling them all as I4 I get a System.ArgumentException

An unhandled exception of type 'System.ArgumentException' occurred in SomeDll.dll    
Additional information: Type 'Namespace.Document+SomeNativeStruct' cannot be marshaled as an unmanaged structure; no meaningful size or offset can be computed.

Answer 1

bool is a tricky type to interop. There's many mutually incompatible definitions of what a boolean value is, so bool is considered a non-blittable type - that is, it needs to be truly marshalled, rather than just sticking a "totally a bool" tag to the data. And arrays of non-blittable types are doubly-tricky.

The simplest solution would be to avoid using bool entirely. Just replace the bool[] with int[], and provided the original type is actually a 32-bit int (depends on the compiler and platform), you'll get correct interop. You can then manually copy the interop struct to a managed struct with a more sane layout, if you so choose - which also gives you full control over interpreting which int values correspond to true and false, respectively.

In general, native interop is always tricky; you need to have a good understanding of the actual memory layout as well as the meaning of the values and types you're dealing with. The types aren't enough - they're too ambiguous, especially in standard C (which is often the standard for native interop even today). Headers aren't enough - you also need the docs, and perhaps even a look in a (native) debugger.

Extra danger comes from the fact that there's no safety net that tells you you're doing things somewhat wrong - the wrong interop approach can appear to work just fine for years, and then suddenly blow up in your face when e.g. a true value happens to be 42 instead of the more usual -1, and your bitwise arithmetics breaks subtly (this can actually happen in C#, if you use unsafe code). Everything might work great for values smaller than 32768, and then break horribly. There's plenty of hard to catch error cases, so you need extra caution.