Shared Library limitations on null pointers

In my 2011b documentation file under "Calling Functions in Shared Libraries" there's a section on the "Limitations Using Pointers". It says in it that,

"The shared library interface does not support library functions that work with function pointers. If the functions accepts a NULL pointer, it is possible to call the function, but it may not be useful."

However, in the documentation online http://www.mathworks.com/help/techdoc/matlab_external/f43202.html it says. The second sentence is not there! Is the null pointer issue solved? I'm calllib-ing a C++ function from a shared library (of some purchased device's dll) which needs a double-typed pointer to an empty 2D array as an input argument. The return value shows fine, but the function didn't work as it should (this sounds like the situation as in the second sentence says). I set up the pointer as,

sdata = zeros(16,2048); sdataPtr = libpointer('doublePtr', sdata);

Other functions I tried in the same dll worked fine (some need a longPtr with a non-empty value). Does this have to do with the problem of Matlab's limited functionality in using shared library?

If you think this question is too specific to answer, is it possible to give an example of the null pointer case that matches the situation mention in the documentation. What should I do if I really need a null pointer? Writing up a mex file?

[Philip Borghesani]

We need more specifics to answer the question. What is the function you are trying to call and what is it's prototype. Can you supply any documentation on it's inputs? "Empty 2D array" is not specific enough information. It does not sound like your function uses function pointers so the quoted sentence does not apply.

[Kunz]

I've included more details in my latest response. Since this is a function in the library written for a CCD's peripheral electronics by some company that are not meant to be used explicitly in Matlab but C++. I just want to try using the shared library to call directly before resorting to writing a mex file. So far this is the only function that I haven't figured out before getting the data out from the computer memory (will be written into this array).

Answer 1

[Walter Roberson]

http://c-faq.com/ptrs/generic.html

If you do not happen to be a C geek, the discussion reads like an argument about how many boson particles can dance on the head of a pin.

In theory, in C you cannot convert between a pointer to data and a pointer to a function. Pointers to data can be converted to pointers to other kinds of data, and pointers to functions can be converted to pointers to other kinds of functions, but the two are in theory not allowed to mix.

In practice, on every architecture and operating system that MATLAB itself is supported on, the two kinds of pointer are the same size, and in practice a void* pointer can be used to hold a function pointer on those systems.

This practical approach applies to many of the processors that MATLAB Code Generator and Simulink Code Generator know how to do with, but it does not apply to all systems.

There are particular problems in this regard on systems with Harvard architectures, which a number of embedded processors do have:

Also, a Harvard architecture machine has distinct code and data address spaces: instruction address zero is not the same as data address zero. Instruction address zero might identify a twenty-four bit value, while data address zero might indicate an eight bit byte that isn't part of that twenty-four bit value.

So, it is not completely safe to treat instruction pointers (function pointers) and data pointers as the same length when you are dealing with embedded processors, but in cases where you are working on the x86 or x64 architecture that MATLAB itself executes on (and all current MS Windows except CE), you can receive and send out function pointers by saying you are dealing with a void*

[James Tursa]

Clarification: In Standard C you cannot, in general, convert a pointer to type A to a pointer to a different type B. The exception being if one of A or B is char. (As you point out, however, they are typically the same size on MATLAB installations and the processor will allow it)

[Walter Roberson]

char* was pre-ANSI . ANSI C (1989) uses void* as the generic pointer that all data pointer types are convertible to, and which can be converted to all data pointer types.

There have been general purpose systems on which different pointers were different sizes; see http://c-faq.com/null/machexamp.html

Answer 2

[Kunz]

Thanks Walter. I tried changing the second line to,

sdataPtr = libpointer('voidPtr', sdata)

but the results are the same, sdata returned intact. In fact, in the libfunctionsview window this function as GetStoredRawData(longPtr, doublePtr). I'm sure the longPtr part is right since some other functions needs to be passed in arguments the same way. But this doublePtr argument is new. I also tried generating the empty array with,

sdata = double.empty(16,2048,0)

and convert it to a pointer (doublePtr or voidPtr), but this just crashes Matlab by raising a segmentation violation error.

P.S. I'm a physics major but not a C-major, so an interacting boson problem is more transparent to me than this...

[Walter Roberson]

Sorry I got side tracked and did not read your original question through.

What you are doing has nothing to do with function pointers. A function pointer is a pointer to a _function_. For example, a generalized "sort" routine takes a pointer to the data and a pointer to a function, with the function being called to decide whether one element is "before" another. (In this way you do not need a different sort algorithm for each different data structure.)

Because your question has nothing to do with pointers to functions being passed around, the second sentence (or lack of it) is irrelevant to your situation.

=====

It seems it is my turn to cook, so I will re-read this all later.