Returning mxArray* as void* from a C shared library

For a C function that inputs an mxArray*, one can simply:

   calllib(mylib, 'myinputfun', myarray);

If the C function instead inputs a void* (reinterpreted within the function as an mxArray*), then this works:

   calllib(mylib, 'myinputfun', libpointer('MATLAB array', myarray));

Similarly, if the C function returns an mxArray*:

   myarray = calllib(mylib, 'myoutputfun');

When returning a void* (that actually is an mxArray*), a libpointer with a voidPtr type is returned, which makes sense. However I'm having difficulty accessing the underlying value. I would expect something like this to work, but I cannot seem to cast the pointer to a 'MATLAB array'.

   mypointer = calllib(mylib, 'myoutputfun');
   setdatatype(mypointer, 'MATLAB array', size);
   myarray = mypointer.Value;

I am aware that it would be simpler to work with native types like double*. The reason I require this is because the functions I have are actually creating and returning mxGPUArray*, and I need to preserve the array structure in order preserve its data pointer to GPU memory (hope that makes sense).

Answer 1

[Philip Borghesani]

Passing mxArrays via void pointers is likely to cause problems in your code (memory leaks and crashes). The calllib code has special handling for transferring ownership of mxArrays when needed but it can't do this when they are passed as a void pointer. If you whish to avoid including mex.h I suggest adding a forward deceleration for mxArray to your header file instead:

typedef struct mxArray mxArray;

[auneri]

Perfect! this answers my question and provides the rationale, thank you.

Answer 2

[James Tursa]

Can you create your own custom header file for this library when you load it with loadlibrary, with the (void *) for the function in question changed to (mxArray *) ?

[auneri]

Yes I can, in fact that is how I validated that returning mxArray* works as intended. This however requires the header to include mex.h, which I am trying to avoid for other reasons.

[James Tursa]

But this is a header for just loadlibrary to use. Why to you need to avoid mex.h?

[auneri]

While there may be a way to include it without causing to much fuss, my main reasons were:

1. The same header is actually used by other languages as well, which is why I like to keep it pure C.
2. The compiled library in the backend has an option to build w/ & w/o MEX support, such that mex.h is not in include path (nor is needed) when MEX support is disabled.

[James Tursa]

I think maybe you missed the point. You can keep your original header file in pure C, and not change any of your build practices or how you compile the library. This extra header file with (mxArray *) is off to the side, outside of your normal build, and only used for one purpose ... to feed the MATLAB loadlibrary function.