So it’s garbage… Is mapping between a bits type and C like this allowed? I know I could use an immutable with the same structure as the C struct, but let’s say for the sake of argument that the data should be opaque on the Julia side and I really want a bitstype, is it possible? Asking in the context of CxxWrap, where I’m trying to avoid boxing bits types like this.
No. The calling convention depends on the field types so it’s impossible to get it right without knowing the field types. It doesn’t matter (more or less, apart from alignments) of course if you are only passing pointers.
enum is not a struct. It’s simply a constant integer in C so you should just pass it as such. Note that the size of enum is actually implementation defined (unless explicitly specified in c++11) so matching with a julia enum may not work. Using a integer type with the same size as the one returned by clang should work.
Sort of, I was thinking of defining a bits type on the C side using jl_new_bitstype and making sure its size is exactly the same as the size of the C enum (I didn’t realize this was implementation defined, actually). The values themselves would also be populated on the C side, using jl_set_const I think (not tried yet). The advantage in the context of CxxWrap would be strongly typed enums with values set on the C++ side, ensuring consistency of the values even when the headers change.
This seems to work everywhere (Linux gcc, OSX clang, Windows MSVC) except on mingw (Julia 0.5 and 0.6, mingw64 gcc 5.3 and 6.2) where it still gives garbage, output of the test:
Returning ImmutableDouble with value 1
imdbl.value = 9.26849808e-315
Am I still violating the ccall protocol here or is there a bug in either mingw or Julia?
The compiler you uses to compile julia should not affect the ccall calling convention.
It’s the most likely that you are missing a calling convention specification. (cdecl/stdcall etc.) It’ll be very surprising if mingw uses a completely different/new calling convention on windows.