1615 Is there a Tutorial for Creating MEX-files with Emphasis on C MEX-files?

Introduction

This tutorial provides a general overview of MEX-files and a detailed explanation of the external interface functions that allow you to interface C or Fortran subroutines to MATLAB. It includes C MEX-file code examples that demonstrate the use of the external interface functions.

MEX stands for MATLAB Executable. MEX-files are dynamically linked subroutines produced from C or Fortran source code that, when compiled, can be run from within MATLAB in the same way as MATLAB M-files or built-in functions. The external interface functions provide functionality to transfer data between MEX-files and MATLAB, and the ability to call MATLAB functions from C or Fortran code.

MATLAB for Windows supports two formats for MEX-files: REX (Relocatable Executable) format and DLL (Dynamic Link Library) format.

The REX format uses 32-bit code, thus yielding performance comparable to MATLAB's built-in functions. REX-format MEX-files are recommended for numerically intensive applications.

The DLL format (which is 16-bit code) yields slower performance and necessitates the use of huge pointers to deal with matrices larger then 64k. The advantages of using a DLL format is that it allows you to access the functions in the Windows environment (i.e., to create custom user interfaces for your applications).

Why Use MEX-files?

• MEX-files interface large pre-existing C or Fortran code with MATLAB without rewriting the code in MATLAB.
• The algorithm to be implemented contains some for and while loops that can not be vectorized. MATLAB may not process loops as quickly as C or Fortran code. MEX-file loops run at normal C or Fortran code speed, resulting in a substantial performance increase.

• To access hardware. For example, MEX-files can be used to access A/D and D/A boards.
• In MATLAB for Windows, custom Windows user interfaces can be created.

Components of MEX-files

There are a number of issues that need to be understood in order to write your own C MEX-files.

• The source code for a MEX-file consists of:

  Computational routine - which contains the actual code that you want implemented in the MEX-file. It is called by the gateway routine (for short MEX-files, the computational routine code can be included in the gateway).

  Gateway routine - which interfaces the computational routine with MATLAB: It calls the computational routine.

• All C MEX-file source code must contain the statement

#include "mex.h"

so that the entry point and the interface routines are declared properly (Fortran does not include this file).

• The entry point to the gateway routine must be named mexFunction. This function acts similarly to the function main() in a standalone C program, in that it is where the function MEX-file starts executing when MATLAB calls it. mexFunction has four input arguments, and must be prototyped in one of two ways, depending on if the compiler is ANSI C compatible. For example:

ANSI (standard C):

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

Non-ANSI (Traditional C, Original C, old C, K&R C):

mexFunction(nlhs, plhs, nrhs, prhs)
int nlhs, nrhs;
Matrix *plhs[], *prhs[];

Example of the World's Smallest MEX-file

/* The following is the world's smallest MEX-file that
   actually does something.  
   Note that it is written in ANSI C.
*/

#include "mex.h"

void mexFunction(int nlhs,
                 Matrix *plhs[],
                 int nrhs,
                 Matrix *prhs[])
     {
     mexPrintf("Hello world");
     }

mexPrintf(format,...) is, for the most part, just like C's printf function. See the FAQ at the end of this document for exceptions. format is a format-specifier string, which can be followed by some arguments. mexPrintf uses the format-specifier string to print the arguments (or the contents of the arguments, if they are variables) to the MATLAB command window. For example,

mexPrintf("This is an integer: %d.",5);

would print

This is an integer: 5.

MATLAB Variables (Matrices)

Before we can discuss the inputs and outputs of MEX-files, we need to understand what a MATLAB variable is.

Each MATLAB variable is a matrix (even strings and scalars are considered to be matrices). A matrix is the C-language definition of a MATLAB variable. It is a structure containing the following information:

Matrix's name (name)
Matrix's dimensions (m and n)
Arrays of the matrix's real and imaginary parts (pr and pi)
If sparse, arrays describing the matrix's structure (ir, jc, nzmax)

>>A =
   1.0000 + 1.0000i   2.0000             3.0000          
   4.0000             5.0000 + 1.0000i   6.0000          

would be stored in the matrix (or C structure) as

Matrix.name     ="A"
Matrix.m        = 2
Matrix.n        = 3
Matrix.pr[0]    = 1.0     Matrix.pi[0]  = 1.0
Matrix.pr[1]    = 4.0     Matrix.pi[1]  = 0.0
Matrix.pr[2]    = 2.0     Matrix.pi[2]  = 0.0
Matrix.pr[3]    = 5.0     Matrix.pi[3]  = 1.0
Matrix.pr[4]    = 3.0     Matrix.pi[4]  = 0.0
Matrix.pr[5]    = 6.0     Matrix.pi[5]  = 0.0

The structure of sparse matrices is not dealt with in this tutorial. However, it's described in the Sparse Matrices section of this document.

Inputs and Outputs of MEX-files

Inputs

• nrhs: number of right-hand side arguments
• prhs: pointer to right-hand side arguments

Outputs

• nlhs: number of left-hand side arguments
• plhs: pointer to left-hand side arguments

The variables nlhs and nrhs specify the number of left-hand and right-hand side arguments that are used when the MEX-file is called. They are analogous to the MATLAB variables nargout and nargin, respectively. For example, if the MEX-file was called in MATLAB using

[a,b]=mymexfunction(d,e,f)

then nlhs equals 2 (for a and b), and nrhs equals 3 (for d, e, and f).

prhs is an array of pointers to the input matrices. Thus, in the above example, plhs[0] is a pointer to the matrix d, and prhs[1] is a pointer to the matrix e. plhs is an uninitialized array. If plhs is greater than zero, then the MEX-file should fill the plhs array with pointers to matrices containing valid data, or generate an error message stating that too many outputs were requested.

The MEX External Interface provides several functions that allow you to determine various states of a matrix. These functions are used to check the input to the MEX-file to make sure it's what's expected. The functions that have the prefix mxIs are:

i = mxIsComplex(mp)                   i = 1 if pi<>NULL, 0 otherwise        
i = mxIsFull(mp)                      i = 1 if matrix is Full, 0 if         
                                      matrix is sparse                      
i = mxIsSparse(mp)                    i = 1 if matrix is Sparse, 0 if       
                                      matrix is Full                        
i = mxIsNumeric(mp)                   i = 1 if matrix is numeric, 0 if      
                                      matrix is a string                    
i = mxIsString(mp)                    i = 1 if matrix is a string, 0 if     
                                      matrix is numeric                     
i = mxIsDouble(mp)                    i = This is for future                
                                      compatibility, in case matrices       
                                      ever contain non-double elements.     

In order to prevent passing inputs that are the incorrect type, use the mxIs* functions extensively at the beginning of your MEX-file. For example, suppose prhs[0] is supposed to be a regular, full, real-valued matrix. To prevent passing your function a sparse matrix, a string matrix, or a complex matrix, use code similar to the following:

if ( mxIsComplex(prhs[0]) || mxIsSparse(prhs[0]) || \\
     mxIsString(prhs[0]) )
     mexErrMsgTxt("first input must be real, full, \\
     and nonstring");

Putting these checks in prevents your MEX-file from crashing, for no apparent reason, when you accidentally pass it the wrong type of data.

Example: MEX-file Checking Inputs and Outputs

/* The following is a very basic MEX-file that checks to 
   make sure that its input is a scalar.  Note that it
   is written in ANSI C.                 */

#include "mex.h"

void mexFunction (int nlhs,
                  Matrix *plhs[],
                  int nrhs,
                  Matrix *prhs[]);





{
  int m, n;
  double x, *y;

  /* check: only one input and one output argument */ 
  if (prhs != 1)
    mexErrMsgTxt("Must have one input argument");
  if (prhs != 1)
    mexErrMsgTxt("Must have one output argument");

/* prevent you from passing a sparse matrix, a string 
   matrix, or a complex matrix */
if ( mxIsComplex(prhs[0]) || mxIsSparse(prhs[0]) || \\
     mxIsString(prhs[0]) )
  mexErrMsgTxt("Input must be real, full, and \\
                nonstring");
}

The MEX-file example first checks to make sure that the function was called correctly, with the correct number of inputs and outputs. It verifies that the input is a scalar. Then, using the mxIs* functions, it verifies that the input is a full nonsparse matrix. Finally, it gets the pointer to the real part of the output matrix and fills in its first element with the function's output.

Allocating Matrix Structures

The MEX External Interface provides three functions to create matrices to be passed to MATLAB.

• mxCreateFull
• mxCreateSparse
• mxCreateString

To clear the matrix structure defined by the above functions use:

 mxFreeMatrix

Creating Matrices:

mp=mxCreateFull(m,n,complex_flag) allocates memory for a new full m by n matrix. complex_flag is REAL for a real matrix, and COMPLEX for an imaginary/complex matrix.

mp=mxCreateSparse(m,n,nzmax,complex_flag) allocates memory for a new sparse m by n matrix. Nzmax is the maximum number of nonzero elements in the sparse matrix. complex_flag is as above.

mp=mxCreateString(str) allocates a string matrix and copies the contents of str into it.

mxFreeMatrix(mp) frees (destroys) a full or sparse matrix.

Accessing String and Scalar Matrices:

errcode=mxGetString(mp,str,strlen) copies up to strlen characters out of the matrix mp into the character buffer pointed to by str. str must be preallocated either statically or via mxCalloc. Errcode is 0 for success, 1 if mp is not a string matrix or length of mp is greater than strlen.

x=mxGetScalar(mp) returns the (1,1) element (of the MATLAB matrix) of the matrix mp.

Allocating/Deallocating Memory:

voidptr=mxCalloc(n,size) - is similar to the C calloc function, but allocates memory from the MATLAB heap. n is the number of elements to allocate; size is the size of each element.

mxFree(voidptr) - is similar to the C free function. It frees/deallocates memory allocated with mxCalloc.

Accessing Individual Members of Matrix Structures

These functions provide access to the individual matrix structure members.

Matrix member	Type	To read from Matrix	To write to Matrix
name	char *	str = mxGetName(mp)	mxSetName(mp,str)
m	int	i = mxGetM(mp)	mxSetM(mp,i)
n	int	i = mxGetN(mp)	mxSetN(mp,i)
pr	double *	xp = mxGetPr(mp)	mxSetPr(mp,xp)
pi	double *	xp = mxGetPi(mp)	mxSetPi(mp,xp)
ir	int *	ip = mxGetIr(mp)	mxSetIr(mp,ip)
jc	int *	ip = mxGetJc(mp)	mxSetJc(mp,ip)
nzmax	int	I = mxGetNzmax(mp)	mxSetNzmax(mp,i)

Where mp represents type Matrix *

With the matrix access routines provided by The MathWorks, it is not necessary to know the actual structure of a matrix. The matrix access functions, which all begin with the sentinel characters mx, provide access to the matrix, which allows for future changes in the structure of the matrix without having to rewrite MEX-code.

Note that the mxSet* commands are "dumb." That is, if you set one part of the matrix using an mxSet* function, then it is up to you to make sure the rest of the matrix contents are consistent. For example, if you set m and n to be 3 and 2, it is up to you to make sure pr and pi are six element arrays of doubles.

Example: MEX-file Accepts One Input and Returns One Output

/* The following is a very basic MEX-file that returns
   the input value plus 1. Note that it is written in
   ANSI C.
*/

#include "mex.h"

void mexFunction(int nlhs, 
                 Matrix *plhs[],
                 int nrhs, 
                 Matrix *prhs[])
{
int m, n;
double x, *y;

 m = mxGetM(prhs[0]); /* get the dimensions of the 
                         input */
 n = mxGetN(prhs[0]);

/* make sure input is 1x1 */
  if (m*n != 1) 
  mexErrMsgTxt("Input must be a scalar");

/* Create/allocate return argument, a 1x1 real-valued
   Matrix */
  plhs[0]=mxCreateFull(1,1,REAL); 

/* Get pointer to real part of return argument */
  y = mxGetPr(plhs[0]);  

  x = mxGetScalar(prhs[0]);  /* Get value of input */

  y[0] = x + 1; /* assign a value to return argument */
}

Registering an Exit Function

Another advantage of MEX-files is that they can have static memory. This means that variables inside the MEX-file that are declared static retain their values from call to call of the MEX-file. Any initialization of these variables occurs when the function is called for the first time, i.e. when the function is loaded into memory.

Certain events can cause MATLAB to remove the MEX-file from memory. Some examples of these events are:

• You execute clear, clear all, clear mex, or clear <mexfunction>.
• You issue the pack command.
• MATLAB needs to free up some memory for a new variable.
• MATLAB is terminated.

An exit function is called by MATLAB just before it unloads its corresponding MEX-file. Each MEX-file is allowed to have its own exit function, but no MEX-file can have more than one exit function. The MEX-file registers its exit function by calling the mexAtExit function. The exit function must return a void, and cannot accept any input arguments.

This example shows an exit function, as well as the corresponding call to mexAtExit, registering the exit function:

void myExitFcn() {
      mexPrintf("Warning, MEX-file is being unloaded");
}

/* Later on, inside the mexFunction ... */
if mexAtExit(myExitFcn)
       mexPrintf("Error, myExitFcn not registered //
properly");

Data Transfer: MEX-files <==> MATLAB

These functions allow you to pass matrices to and get matrices from MATLAB.

Get Matrices from MATLAB                 Put Matrices in MATLAB                   
mexGetMatrix *                           mexPutMatrix *                           
mexGetFull *                             mexPutFull **                            
mexGetMatrixPtr*                                                                  

*  To clear use mxFreeMatrix
**  To clear use mxFree

Passing Matrices Between MEX-files and MATLAB

Usually, matrices are passed to MATLAB via the right-hand side (rhs) and the left-hand side (lhs) method. This means that variables are passed into and out of a function by being included as arguments to the function. Sometimes, there are cases in which you may need to violate this standard. Some examples are:

• You have more than 50 input or output variables (MATLAB has a limit of 50)
• You want to modify many variables using a function, and you don't want to have to type

  
  [a,b,c,d,e,f,g,h,i,j,k,l,m,n,o,...] = func(a,b,c,d,e,f,g,h,i,j,k,l,m,n,o,...)
  

  
  

function thefun
x=5; y=0;
themexfun(x);

Even though themexfun is only passed the variable x, it can still gain access to the variable y. The following code fragment shows one way this can be done from inside the MEX-file (assuming mp is a Matrix *):

Matrix *mp;
mp = mexGetMatrix("y");

When this code is executed, a copy of the variable y is made, and mp is assigned to point to it. Because a copy of the variable is made, you must remember to free mp with mxFreeMatrix when you are done with it.

The following examples describe the three mexGet* functions that can access a matrix in more detail. The examples use these variable declarations:

Matrix *mp;
int m,n, errcode;
double *pr, *pi;
char *name;

1. Example of using mexGetMatrix()

   mp=mexGetMatrix(name) - Make a copy of the matrix whose name is specified by name from the calling function's workspace. Return a pointer to the copy, or NULL if the matrix doesn't exist. Remember to free mp with mxFreeMatrix.

   Matrix *mymatrix;
   
   if ((mymatrix = mexGetMatrix("a"))==NULL)
   mexErrMsgTxt("Variable 'a' does not exist in workspace.");
   else {
   <do stuff with mymatrix>
   mxFreeMatrix(mymatrix);
   }
   

   
   

2. Example of using mexGetFull()

   errcode=mexGetFull(name,&m,&n,&pr,&pi) - Similar to mexGetMatrix, but instead of returning a matrix pointer, the various elements of the matrix are copied directly into m, n, pr, and pi. Note that you do not need to allocate memory for pr and pi, because mexGetFull does this for you. But, you do need to free pr and pi with mxFree when you are done with them. As its name implies, this function can only be used with full matrices, not sparse ones. Errcode is 0 if successful, 1 if the matrix doesn't exist.

   	
   int m,n;
   double pr[], pi[];
   
   if mexGetFull("a",&m, &n, &pr, &pi)
   mexErrMsgTxt("Variable 'a' does not exist in workspace.");
   else {
   <do stuff with m, n, pr, pi>
   mxFree(pr);
   mxFree(pi);
   }
   

   
   

3. Example of using mexGetMatrixPtr()

mp=mexGetMatrixPtr(name) - Again, similar to mexGetMatrix, but instead of making a copy of the matrix, a pointer to the original matrix is returned. The only thing you should do with mp is change the data in the matrix or use its contents for calculations.

Do not change the dimensions, sparsity, or complexity of the matrix.

Matrix *mymatrix;

if ((mymatrix = mexGetMatrixPtr("a"))==NULL)
mexErrMsgTxt("Variable 'a' does not exist in workspace.");
else {
     <do stuff with mymatrix>
     }

MEX-files can also place variables into the calling function's workspace. When doing this, if a variable with the same name already exists in the calling function's it is deleted and replaced with the new variable. Otherwise, the variable is simply placed into the workspace. For example, suppose this code appeared in the MEX-file themexfun:

Matrix *mp;

mp=mxCreateString("Hi there");
mxSetName(mp,"A");
mexPutMatrix(mp);

Assume that before running themexfun, there were no variables in the current workspace. After running themexfun, there would be a variable named A in the current workspace, containing the string Hi there.

The following describes the two functions that allow for putting matrices into a workspace. The same declarations as above are used here:

errcode=mexPutMatrix(mp) - Put a copy of the matrix pointed to by mp into the calling function's workspace. If a variable with the same name already exists there, it is replaced. errcode is 0 for success and 1 if an error occurred.

errcode=mexPutFull(name,m,n,pr,pi) - Similar to mexPutMatrix, but rather than taking a pointer to a matrix as input, the various parts of a full matrix are passed to it instead. This function allocates a matrix of size m by n, copies the data from pr and pi to it, and gives it the name specified by name. It then passes the matrix to the calling function's workspace in the same way as mexPutMatrix. As with mexPutMatrix, errcode is 0 for success and 1 if an error occurred.

In general, use caution when using any of the mexGet* or mexPut* functions. These functions, especially the mexPut* functions, are likely to have strange side effects, which at best create strange variables in your workspace, and at worst write over your data without you knowing about it. These effects are documented in the function's on-line help.

Calling MATLAB Functions From MEX-files

The next two functions allow you to call other MATLAB functions.

*  mexEvalString
*  mexCallMATLAB

Calling Another Function from a MEX-file Using mexEvalString

errcode=mexEvalString(str) - Similar to MATLAB's eval function, this function evaluates its string input in the calling function's workspace, in the same manner as if it had been entered at the MATLAB command line. For example,

mexEvalString("p=plot(1:10);");

would generate a plot of 1 to 10 in the current figure window. Note that since the command is evaluated in the calling function's workspace, the variable p is stored in the calling function's workspace. Thus, if the MEX-file were to be called from within an M-file function, p would be stored in that function's workspace, not the main workspace.

Although mexEvalString is easy to code, the string passed to mexEvalString is evaluated by MATLAB, therefore, the MATLAB parser has to be called. Calling another MEX-file via the mexEvalString is not very efficient since the MATLAB parser is called. Also, all variables created by the mexEvalString command are stored in the workspace of the function text called by the MEX-file, which may need to be retrieved with the mexGet* functions. A more efficient way to accomplish the same goal is to use the mexCallMATLAB function (assuming you're calling a function and not a script).

Calling Another Function from a MEX-file Using mexCallMATLAB

Other MATLAB functions, including built-in functions, MEX-file and M-file functions, (not M-file scripts) can be called from within a MEX-file using the mexCallMATLAB function.

This function accepts five inputs. The first four are structured exactly the same as the inputs to mexFunction which are nlhs,plhs,nrhs, and prhs, are int's, and plhs and prhs are pointers to arrays of matrices. You set up nrhs, prhs, and nlhs to contain what you want passed to the MATLAB function that you are calling. The function returns any output data in plhs. Thus, it is as if your MEX-file is acting as the MATLAB parser, arranging the data in the correct data structure and passing it to the function. The fifth argument is a character string containing the name of the MATLAB function to be called. The following is an example of this that calculates the determinant of a matrix and prints it out. The example assumes the matrix pointer mp has already been initialized to contain valid data:

int nlhs1, nrhs1;  /* chances are plhs and prhs are
                      already used by mexFunction */

Matrix *plhs1[1], *prhs1[1];

prhs1 = 1;         /* One output requested from the
                      'det' function */
prhs1 = 1;         /* One input passed to the 'det'
                      function */

prhs1[0] = mp;     /* Set up input argument to 'det' */

mexCallMATLAB(nlhs1,plhs1,nrhs1,prhs1,"det");
mexPrintf("Det(mp) == %g",mxGetScalar(plhs1[0]));
mxFreeMatrix(plhs1[0]);

There are three things to note here.

1. Any variable created by the MATLAB function and returned (by mexCallMATLAB) in the plhs data structure must be freed by your MEX-file when you are done with it.

2. Even if a function is called with nlhs equal to zero (no output arguments requested), it can still return up to one matrix. This matrix is assigned to the built-in variable ans if the function is called from the command line. Therefore, even if you set nlhs to zero when calling mexCallMATLAB, you should still make sure that plhs contains space for at least one output matrix, and you should never pass NULL for plhs. *plhs is an array of matrix pointers. If nlhs == 0 this means plhs[0] == NULL and not plhs == NULL. Therefore, the correct syntax to assign plhs when there are no output arguments is:
   plhs[0] = NULL;

3. You can access MATLAB's operators, such as * (multiplication) and / (division), by specifying the operator in string form as the fifth input to mexCallMATLAB.

The following is a list of all the valid operators that can be used with the mexCallMATLAB function:

Thus, to add two matrices together, you could make the following call (assuming prhs already contains the two matrices):

mexCallMATLAB(1,plhs,2,prhs,"+");

Ordinarily, if an error occurs in the function call made by mexCallMATLAB, MATLAB prints the appropriate error message and returns to the command prompt. However, by using the mexSetTrapFlag function, you can change this behavior. Calling mexSetTrapFlag(1) will set the trap flag so that if an error occurs, mexCallMATLAB will return control to the MEX-file. mexCallMATLAB will then return an integer error code of zero if the function call was successful, and nonzero if an error occurred. Calling mexSetTrapFlag(0) returns mexCallMATLAB to its default behavior.

Sparse Matrices

The best way to explain how sparse matrices are stored in matrix structures is through an example.

Given a 4-by-4 full matrix A:

>>A =   [0 0 0 1
         0 5 0 0
         0 0 7 6
         0 9 8 0]

and converting it to a sparse matrix results in the following sparse matrix characteristics:

nzmax = 6     % maximum number of non-zero elements
    m = 4     % number of rows
    n = 4     % number of columns

pr is a pointer of type double

ir and jc are arrays of type integers

Note: Indexing off of 0 (not 1) will be used to reference elements of the pr, ir, and jc arrays and also of the matrix A.

Each element in the ir array indicates in which row (of the A matrix) the corresponding value (using same index as in ir) in pr is located.

For example, the first element (the zero'th index) in the ir array is 1, thus the corresponding element (zero'th index of pr) in pr is in row 1 of array A (indexing A off of zero). Here's a table of the first few elements:

The jc array is a little more tricky. If you traverse the A matrix (indexing off of 0) in a column order and you only count the nonzero elements, it results in the following vector of nonzero elements:

By looking back at the A matrix you see that the values 5, 7 and 1 are the first nonzero occurrences in each row. These values correspond to the indices 0, 2, and 4 of the vector created of all the nonzero elements of the A matrix.

The jc array is made up of indices of the first nonzero element for each column of the A matrix. jc arrray always starts with 0; whether it is because the 1st column of A contains all zeros or because the 1st non-zero element of the 1st column of A is in the 0th index of pr. The second entry of the jc array is the number of non-zero elements prior to the second column of the matrix A and the third and the fourth entries are the number of non-zero elements prior to the third and fourth columns, respectively. This paradigm can be followed for larger sparse matrices. The final value of the jc array is the actual number of the non-zero elements in the matrix; thus, for matrix A, it is 6. Therefore, the jc array is:

Summary of Terms and Acronyms

List of External Interface functions

Frequently Asked Questions (FAQ) about MEX-files

Question

What do the following error messages mean (compiling with Metaware High C 3.01)?

error: multiple entry points record in module "init".
error: duplicate definition of symbol "_unlink"
error: undefined symbol "main" in module "init"

Answer

Errors such as the ones above, that have to do with entry points and initialization, often occur due to slight differences between the compiler being used and the compilers that are officially supported by The MathWorks. Despite the error message, many times a working MEX-file is created. If a MEX-file is created after getting these error messages, try running the MEX-file to see if it works correctly. If it does, ignore the error message.

Question

How can I access a global variable from inside a MEX-file?

Answer

In MATLAB 4.2, there is a new mex* function called mexGetGlobal that will access global variables for you. It uses the same calling syntax as mexGetMatrixPtr.

Question

When creating DLL MEX-files I either get unresolved reference errors for matOpen, matClose, matGetMatrix, and matGetDir functions, or unresolved external sscanf. Why?

Answer

MEX-files created by Microsoft's Visual C++ and Borland's C/C++ are implemented as (16-bit) DLL functions. Microsoft and Borland do not support the sscanf function within DLL functions. Since the libmat.lib library that supplies the mat* functions requires the sscanf function, there is no way to call mat* functions from a DLL MEX-file.

Question

Printing with the %f, %g, and %e printf format specifiers within DLL functions do not appear to work. Why?

Answer

Microsoft and Borland do not support the %f, %g, and %e format specifiers in DLL functions.