Question

I’m working on a Matlab code that takes video frames, puts them inside a cell array such as

frames{fr} = read(videoObj, fr);

For a sample video, I check the frames cell, and it contains 84 frames (video has 84 frames), and all cells are full with images.

I have a mex file, as standard, it is such as

void mexFunction(int nlhs, mxArray *plhs[], int nrhs, const mxArray *prhs[])

As I have read the properties of mex file creation, they say input prhs is const mxArray so that whatever happens inside the mex code, input does not change. I give the matlab’s frames cell array as input to mex file as prhs[0] is the frames cell and I do some processing (I swear I don’t change what I take in prhs[0]). However as I debug the Matlab code, I see that right after I call the mex file (and give frames to the mex file as input), last cell of my frames cell seems to be deleted. When I look at 84th cell, it is [], and sometimes it is a random number such as 8 or 4. I don’t understand how or why my frames cell’s last column disappears when I call mex file.

You may think I might have an error in my Matlab code but when I debug, I looked at frames right before the mex is processed, it has 84 cells and last cell is an image as expected, but right after I call the mex, frames is still 84 cells but last cell is [] : empty.

I will appreciate if anyone can help me, why would such as thing happen? Does const mxArray not mean ‘input will not be changed in the mex’ ?

Answer 1

1. The const mxArray* prhs[] covers the pointer to the mxArray[] only. It turns out that it is possible (though highly risky) to change the values of the input arguments inside the mexFunction.

2. Another point worth noting is that although arrays and cells in matlab are indexed from 1..n, in C/C++ (and especially in mex files) elements are indexed from 0,…,n-1. So the fact that in debugger you see that cell[84] is empty (or has a random value in it) is because you are accessing beyond the end of the cell array!