[SOLVED] Why is 'size_t' in external C library interpreted wrong?

I'm running into odd behavior while interfacing with an external C library. For a function like the following,

int foo(size_t sz, uint8_t buf[8])
{
    memset(buf, 0, 8);
    memcpy(buf, &sz, sizeof(size_t));
    return sizeof(size_t);
}

I get the error "Warning: The data type 'error' used by function foo does not exist" when loading the library. And, when I run foo, the contents of buf don't make sense to me. If I change the size_t to uint64_t (or any other suitable integral type), then I get what I expect out in buf.

How is Matlab treating size_t? Why does it appear to be treating it as an 'error' type?

SOLUTION: Added appropriate include (stddef.h) in library header.

Answer 1

[James Tursa]

I am unaware of MATLAB treating size_t differently, but there is a potential error in your code snippet:

int foo(size_t sz, uint8_t buf[8])
    :
    return sizeof(size_t);

The sizeof( ) operator returns a size_t type, but your function returns an int. So on a 64-bit system these will probably not match since size_t is likely a 64-bit integer and int is likely a 32-bit integer. You should change the signature to:

size_t foo(size_t sz, uint8_t buf[8])

What version of MATLAB are you running? 64-bit? Are you using the loadlibrary function? Are you loading a third party library or a library you wrote? Is there a reference to 'error' in the header that you are using? Maybe a typedef?

As for your problem, I don't see a reference to an 'error' data type in your code, so there is nothing for us to analyze.

[Tyson Lawrence]

Sorry for the slow response... holiday weekend.

I'm running 64-bit Matlab. I am not really concerned with the return statement. I probably should have left it out.

I'm working on building a Matlab API for a library I wrote. To interface with the library, I am simpliy using loadlibrary followed by calllibs.

What gets me is the memcpy. If I make foo something like the following (also changing the size_t in the memcpy),

void foo(uint64_t sz, uint8_t buf[8])
void foo(int32_t sz, uint8_t buf[8])

then the contents of buf are what I expect when I call it from Matlab (namely the bytes corresponding to integer value of sz). When the type of sz is size_t, the contents of buf don't make senes to me. For example, when sz is of type uint64_t and sz is set to uint64(2763306), then buf is [42,42,42,0,0,0,0,0]. This is correct. If sz is of type size_t and set to the same value, then buf is [208,166,244,85,37,127,0,0]. I get similar results when I change the type of sz on the Matlab size (in calllib... uint32(sz), int32(sz), uint64(sz), int64(sz), etc...). I also get similar results when I try to pass in 0 for sz.

The warning about the error data type (pasted below) occurs when loading the library.

Warning: The data type 'error' used by function foo does not exist.

> In loadlibrary

This warning only occurs when the data type of sz is size_t. If I change it to another numeric type, it goes away.

All of this makes me think Matlab is doing something different with size_t. There has got to be a reason for it, but I don't know it.

[James Tursa]

I am not sure what is going on yet. Can you double check to see that you have all necessary prototypes in your header file? E.g., if you are using memset( ) and memcpy( ) then you should have

#include <string.h>

in your header file to make sure the prototypes are present. This also defined size_t.

Can you post a small example complete library source code that reproduces the problem?

[Tyson Lawrence]

This is an insanely slow response... I got pulled away from this work for a stretch. I want to add the answer in case others have similar issues.

I resolved the problem by adding the appropriate includes in my library interface (stddef.h in this case). The problem didn't show up in my unit tests or Python API testing, so I missed it. Usually Matlab warns when something is missing.