[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: stroring pointers from oct-files

From: Peter L. Soendergaard
Subject: Re: stroring pointers from oct-files
Date: Mon, 05 Nov 2012 12:00:23 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121016 Thunderbird/16.0.1

On 11/05/2012 10:42 AM, Olaf Till wrote:
On Mon, Nov 05, 2012 at 07:48:45AM +0100, c. wrote:
On 4 Nov 2012, at 20:56, Olaf Till wrote:

On Sun, Nov 04, 2012 at 08:20:20PM +0100, pantxo diribarne wrote:
2012/11/4 Olaf Till <address@hidden>

On Sun, Nov 04, 2012 at 06:55:47PM +0100, pantxo diribarne wrote:

I use octave to comunicate with laboratory hardwares using modbus
through tcp-ip. The modbus library I use (libmodbus:
returns a pointer the modbus "context" variable and then uses this
to access the server.

In octave I cast the adress of the pointer to an "int" type, so that I
reuse that pointer for subsequent calls to one of modbus read/write
functions. I then have to free this pointer before exiting octave. Is it
the righ way to store pointers or is there a proper way to do that?

This could be related to a problem I have written some as yet private
code for, but I'm not sure that I understand you right. Do you pass
the casted pointer to user space (into a variable of the Octave

Right, and there are many functions (oct-files) that rely on that pointer.
The typical way I use those functions is :
octave:1> ctx = modbus_new_tcp ("", 1502); #here ctx is an int
containing the adress of the pointer
octave:2> status = modbus_connect (ctx); #connect to the server
octave:3> #read/write data from/to the modbus server
octave:4> modbus_close(ctx); #disconnect
octave:5> modbus_free(ctx); #free the pointer
Simply passing the (casted) pointer to user space is certainly not the
proper way, since users should not be able to crash Octave. Since the
octfiles have no way to check the validity of the pointer, they would
crash if the user passes a wrong pointer.

To avoid passing the pointer to the interpreter I would have to do that
process (create/open/close/free) in each of the read/write functions
If you have only one pointer per Octave session:

You could code all your functions within one oct-file and store the
pointer in a static variable within that oct-file. Since Octave loads
oct-files without setting the RTLD_GLOBAL flag, you can't easily do
this with multiple oct-files; you would have to dlopen(...,
...|RTLD_GLOBAL) the file with the static variable explicitely.

If you could have a variable number of pointers per Octave session:

Octave AFAIK does not provide a way to store pointers. So you could,
additionally to coding all your functions within one oct-file, provide
a static std::map within this oct-file for storing
pointers. Alternatively, you could use a package of mine which I could
commit to Octave Forge if there is need. It explicitly loads (with
dlopen(..., ...|RTLD_GLOBAL)) a global unique map and implements basic
functions to store and retrieve pointers (casted to (void*)) for use
by other packages or oct-files. Pointers are stored with a unique
label for each pointer type, so if the wrong pointer type is used it
is the oct-file-programmers fault, not the users.

I have not yet suggested to commit the package since my application
for it is not ready to commit. I think ideally such functionality
should be provided by Octave itself, but this does not seem to be
important enough currently.


Alternatively you could define a new class derived from octave_value and store 
your pointer there.
JWE tried a similar thing, see the thread:

but it did not work. The point is that you can't keep track of valid
pointers without a special map, so Octave can be crashed by the user.


I have a similar desire for this functionality, but since I am developing a general toolbox, the solution should also be possible to implement i Mex.

How about returning /two/ integers: First one is the pointer as an integer, second one is a hash of the first one. If the numbers don't match, return a simple error message about invalid input. This should give an additional degree of safety, without requiring a global map.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]