MATLAB Answers


Matlab Coder and the uint64 size_t

Asked by Greg
on 13 Jun 2012
I've been trying to write some Matlab Coder code that needs a bunch of coder.ceval calls to functions in mat.h and mex.h. I've come into a problem, however, because my 64-bit system defines the "size_t" macro as a "long unsigned int", meaning a "uint64" which is not suppoted by codegen. If I attempt to return size_t variables as int32 or uint32, I definitely get the wrong answer (specifically, that sizeof(double)=6, sizeof(char)=4, sizeof(int)=3, etc). Does this mean that the Matlab Coder flat-out does not support coder.ceval calls on 64-bit systems that define size_t as a long int? That seems fairly crippling.

  1 Comment

You found a work-around for this, right?

Sign in to comment.

1 Answer

Answer by Kaustubha Govind on 13 Jun 2012
 Accepted Answer

If you have access to the Fixed-Point Toolbox, it looks like you might be able to get around the limitation the declaring the output of the function as a fixed-point type:
y = fi(0, 0, 64, 0);
Alternatively, you could perhaps create a new "helper" C-function to cast size_t to uint32 for you and use coder.opaque to do something like this:
--- C function prototypes ----
size_t myfun(double u);
uint32_t cast_sizet_uint32(size_t);
---- Using them in MATLAB code for code-generation ---
t = coder.opaque('size_t');
t = coder.ceval('myfun', u); %call function that returns size_t
y = uint32(0);
y = coder.ceval('cast_sizet_uint32', t); %call your helper that does the cast


on 14 Jun 2012
Actually, I figured out that you can typecast within a ceval:
t = coder.opaque('size_t');
t = coder.ceval('sizeof(double)');
y = uint32(0);
y = coder.ceval('(unsigned int)',t);
I believe that codegens C that looks something like:
y = (unsigned int)(t);
Which works, even though it's a bit non-standard-looking.
It's still a little annoying, though, when I have an array of size_t values, such as is returned by mxGetDimensions. My attempts at manual pointer-math haven't been very successful, so I guess the C "helper" function would be the way to go.
Thanks for posting your observations! I would also recommend submitting this as an enhancement request to MathWorks Tech Support so that the development team is aware of the need to address this limitation.

Sign in to comment.