R devel - Sep 2004 - problem typcasting return of R_ExternalPtrAddr(SEXP s)

In the odesolve routine lsoda(), I allow the function (named func) that
calculates the system of differential equations to be defined in a dll that has
been dynamically loaded from the file named in dllname.  I use
getNativeSymbolInfo(func, dllname)$address to get the address of the function 
and pass it to a C function called via the .Call interface.  Inside that C
function,  I use R_ExternalPtrAddr(deriv_func) to get the function pointer. 
This requires typcasting the return value of R_ExternalPtrAddr from (void *) to
(deriv_func *), defined in a typedef in call_lsoda().

To be more explicit (I'm replacing irrelevant arguments with ellipses):
In lsoda(...,func,dllname,...), func contains a string giving the name of a
function which is defined in the dll whose name is contained in dllname.

inside lsoda() are lines like
func <- getNativeSymbolInfo(symbol.C(func),PACKAGE=dllname)

.Call("call_lsoda",...,func)
 
inside call_lsoda.c are the lines:
SEXP func;

typedef void deriv_func(long int *, double *,double *, double *);

derivs = (deriv_func *) R_ExternalPtrAddr(func);


This all worked up to now, but now, (as Kurt Hornik kindly informs me) gcc 3.4
gives the warning:

warning: ISO C forbids conversion of object pointer to function pointer type

so I need to clean this up so odesolve will compile cleanly for version 2.0.0 of
R.  I'm at a loss of what to do, though, since the return value of
R_ExternalPtrAddr is (void *), and I need a function pointer.

I'd guess there would need to be a special function (say declared as 
( R_ExternalFnPtr(SEXP s) *)(), 
or something like that), to make all this work, but I can't find such a
function.   My C programming is pretty rusty, so I'm wondering if someone
has an idea about how I can get around this problem (or perhaps I've
misunderstood the meaning of the error message? )

Woody Setzer

It's a warning, and occurs several times in R itself.  I don't think it
is
fatal to live with it.

There exists systems on which function pointers are not simple pointers, 
but probably none of them run R -- and they do not support dynamic loading 
of packages' DLLs if they do.

On Mon, 20 Sep 2004 wsetzer@mindspring.com wrote:
> In the odesolve routine lsoda(), I allow the function (named func) that
calculates the system of differential equations to be defined in a dll that has
been dynamically loaded from the file named in dllname.  I use
getNativeSymbolInfo(func, dllname)$address to get the address of the function 
and pass it to a C function called via the .Call interface.  Inside that C
function,  I use R_ExternalPtrAddr(deriv_func) to get the function pointer. 
This requires typcasting the return value of R_ExternalPtrAddr from (void *) to
(deriv_func *), defined in a typedef in call_lsoda().
> 
> To be more explicit (I'm replacing irrelevant arguments with ellipses):
> In lsoda(...,func,dllname,...), func contains a string giving the name of a
function which is defined in the dll whose name is contained in dllname.
> 
> inside lsoda() are lines like
> func <- getNativeSymbolInfo(symbol.C(func),PACKAGE=dllname)
> 
> .Call("call_lsoda",...,func)
>  
> inside call_lsoda.c are the lines:
> SEXP func;
> 
> typedef void deriv_func(long int *, double *,double *, double *);
> 
> derivs = (deriv_func *) R_ExternalPtrAddr(func);
> 
> 
> This all worked up to now, but now, (as Kurt Hornik kindly informs me) gcc
3.4 gives the warning:
> 
> warning: ISO C forbids conversion of object pointer to function pointer
type
> 
> so I need to clean this up so odesolve will compile cleanly for version
2.0.0 of R.  I'm at a loss of what to do, though, since the return value of
R_ExternalPtrAddr is (void *), and I need a function pointer.
> 
> I'd guess there would need to be a special function (say declared as 
> ( R_ExternalFnPtr(SEXP s) *)(), 
> or something like that), to make all this work, but I can't find such a
function.   My C programming is pretty rusty, so I'm wondering if someone
has an idea about how I can get around this problem (or perhaps I've
misunderstood the meaning of the error message? )

-- 
Brian D. Ripley,                  ripley@stats.ox.ac.uk
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford,             Tel:  +44 1865 272861 (self)
1 South Parks Road,                     +44 1865 272866 (PA)
Oxford OX1 3TG, UK                Fax:  +44 1865 272595