[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.

回答(1 个)

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.

3 个评论

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.
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?
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.

请先登录,再进行评论。

类别

帮助中心File Exchange 中查找有关 Matrix Indexing 的更多信息

标签

Community Treasure Hunt

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

Start Hunting!

Translated by