mxArray values of plhs[] on entry to mexFunction()

32 views (last 30 days)
AJ
AJ on 9 Dec 2025 at 21:50
Commented: James Tursa on 10 Dec 2025 at 18:32
I consider myself something of a verteran mex programmer.
I was wondering if when the user calls a mex function like this:
[a,b,~,d,e] = my_mex_function(arg1,arg2);
if the mexFunction() has any way to determine of the user specified "~" as the third output argument?
Google AI seems to think that, in this case, plhs[2] will NULL and the others won't but I'm skeptical (and not motivated to test it). I found no supporting documentation.

Accepted Answer

James Tursa
James Tursa on 10 Dec 2025 at 1:34
Edited: James Tursa on 10 Dec 2025 at 18:23
I am unaware of any way to detect this in a mex function. It would be nice, of course, so that mex code could avoid some unnecessary calculations. But I think you are stuck and have to create that third output.
Typically, shared data copies of all plhs[ ] variables are returned to the caller, and then all the temp variables and memory allocated in the mex function are destroyed/freed. My belief is that the unwanted ~ variable gets destroyed at the caller level, but the mex function has no way of knowing that this is about to happen. And, as you noted, there is no specific documentation on how MATLAB actually handles inputs and outputs. In fact, this can change from release to release.
In particular, I don't think you can examine plhs[ ] upon entry to mexFunction( ). I don't think these values are specified to be anything in particular, since it is the programmer's job to fill them in downstream in the code. My guess is they would be all NULL upon entry, since that is how the caller would detect that you didn't fill it in with anything upon exit. If any of them were garbage and not NULL upon entry, and you didn't overwrite them with valid mxArray values, that would likely cause a MATLAB crash downstream, which is why I don't think MATLAB would do this. I just ran a quick check and all of the plhs[ ] values were NULL on entry. Again, there is no documentation about this, but this behaviour seems reasonable.
E.g., this
// tilde.c
#include "mex.h"
void mexFunction(int nlhs, mxArray *plhs[], int nrhs, const mxArray *prhs[])
{
int k;
for( k=0; k<nlhs; k++ ) {
mexPrintf("plhs[%d] = %p\n",k,plhs[k]);
}
}
produces:
>> mex tilde.c
Building with 'MinGW64 Compiler (C)'.
MEX completed successfully.
>> [a,b,~,d,e] = tilde(1,2)
plhs[0] = 0000000000000000
plhs[1] = 0000000000000000
plhs[2] = 0000000000000000
plhs[3] = 0000000000000000
plhs[4] = 0000000000000000
One or more output arguments not assigned during call to "tilde".
>>
  3 Comments
Paul
Paul on 10 Dec 2025 at 13:58
Edited: Paul on 10 Dec 2025 at 18:15
Apparently such a feature is also not available in an ordinary m-function as asked here. Maybe something's changed since that thread, but I couldn't find anything in the doc.
James Tursa
James Tursa on 10 Dec 2025 at 18:32
Follow-up on Paul's comment. One could always add an extra optional input to the mex function that specifies which outputs to generate. If that input is missing, generate all outputs. Otherwise, generate only the ones specified by this input. This extra input could be an array or a string or a single value etc. ... anything that could be used to easily indicate the desired behavior.

Sign in to comment.

More Answers (0)

Products


Release

R2025a

Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!