[Rd] Calling C functions with value parameters

Jeffrey J. Hallman jhallman at frb.gov
Tue Aug 18 15:53:30 CEST 2009


replying to myself here, in lieu of replying to several others

jhallman at frb.gov (Jeffrey J. Hallman) writes:

> One hassle I could do without is the necessity of writing C wrapper functions
> like this:
>
> void fameInit(int *status){
>   cfmini(status);
>   return;
> }
>
> when I want to call a library function (cfmini, in this case) that takes an
> int argument.  The .C interface only lets me pass a pointer to an int, rather
> than the int itself.
>
> Is there any chanch that .C could be enhanced to allow passing arguments by
> value to the compiled code?  It would make some of my stuff much simpler.

Of course I realized right after I posted that my example was incorrect.
Since the cfmini() function takes a pointer to an int, all I needed was this:

status <- .C("cfmini", status = as.integer(0))$status

However, I do have functions where this can't be done, because the library
function being called takes one or more parameters by value, not by reference.
For example, I had to write this wrapper:

void fameCloseDatabase(int *status, int *key){
  cfmcldb(status, *key);
  return;
}

where the "key" argument to cfmcldb() is an int, not a pointer.

As you probably realize, cfmcldb() is not something I wrote: it's part of the
FAME Host Language Interface (chli) provided by Sungard, the vendor of the
FAME time series database.

My point, which I clearly did not make very well, since all of the replies so
far have missed it, is that if .C() could pass arguments by value as well as
by reference, I could write the fame package (an interface to the FAME
database) entirely in R, as I'd be able to call any of the chli functions
directly, without having to write C wrappers.  This would make if much easier
to debug the package and get it working correctly on Windows, where I can't
seem to get it to compile correctly any more.  I surely cannot be the only
package writer who has to interface to external libraries and would rather
write the interface in R than in C.

Do we not all see the virtues of doing almost everything in R itself, rather
than writing parts of the system in other languages and systems?  Why else
would Ripley undertake all the recent work to parse .Rd files in R rather than
in Perl, and why do people work on things like gWidgets?

-- 
Jeff



More information about the R-devel mailing list